next topic »

[Reply #15 on:]

POST Variablen lassen sich nicht "setzen", GET natürlich schon, aber die alleine lassen garnichts zu.

Ist doch aber auch klar: So lange ich einen Client simmuliere muss ich auch mit jedem anderen Client (=Browser) in der Lage sein das nachzumachen.

Und so lässt sich relativ einfach feststellen, dass der eingeschlagene Weg (ohne weitere Unterstützung) ein Holzweg ist.

Mindestens das cURL müsste als Befehl in der Arduino Umgebung funktionieren, was es aber allem Anschein nach nicht tut.

Sorry, aber ich verstehe leider überhaupt nicht was Du mit diesen Sätzen sagen willst. Die POST Daten hat der o.p. ja in seinem Request den er absetzt drin.

Code:

clientBahn.println("date=10.02.12&productClassFilter=1&trainname=874&stationFilter=80&start=Suchen");

Was meinst Du mit

Und so lässt sich relativ einfach feststellen, dass der eingeschlagene Weg (ohne weitere Unterstützung) ein Holzweg ist.

Und wie kommst Du von simulierten Clients (Browser) zu dieser Schlussfolgerung?
Und welcher Befehl soll "cURL" sein?
Ich gebe es zu, aber ich bin verwirrt....

[Reply #16 on:]

Das gibt es fertig zu lesen:

Unterschiede der Methoden GET / POST

http://www.selfphp.info/praxisbuch/praxisbuchseite.php?site=183&group=32

Die geposteten Variablen werden innerhalb der Übertragung des Servers tranportiert, da kann man erst mal nicht eingreifen. Was du im Link zeigst sind GET Variablen, die kann man sehr wohl beeinflussen, dummerweise handelt es sich im vorliegenden Fall aber um beides.

Hinzu kommen alle möglichen Sicherheitsabfragen der Server neuerer Bauart ( sprich Betriebssysteme und deren Kompilate) die nach Spam Methoden suchen, eben genau die, die es im erfolgreichen Nutzungsfalle brauchen würde.

[Reply #17 on:]

Also, wie GET und POST funktioniert, weiß ich schon seit einiger Zeit. Vielen Dank für die Belehrung.

Die geposteten Variablen werden innerhalb der Übertragung des Servers tranportiert, da kann man erst mal nicht eingreifen. Was du im Link zeigst sind GET Variablen, die kann man sehr wohl beeinflussen, dummerweise handelt es sich im vorliegenden Fall aber um beides.

Was meinst Du hier mit "eingreifen"? Wie bereits zweimal im Thread erwähnt, werden die POST Daten mit dem HTTP-Request vom Arduino mitgeschickt. Die entsprechende Zeile hatte ich im übrigen nocheinmal explizit gepostet. Meine Lösung verwendet tatsächlich nur GET Parameter, was ja offensichtlich auch zu funktionieren scheint. Dabei ging es mir vor allem darum, das diese Lösung Speicher- und Programmtechnisch deutlich einfacher und effektiver ist. Das sollte aber nicht bedeuten, das POST nicht funktionieren kann, was Du offensichtlich zu glauben scheinst.

Hinzu kommen alle möglichen Sicherheitsabfragen der Server neuerer Bauart ( sprich Betriebssysteme und deren Kompilate) die nach Spam Methoden suchen, eben genau die, die es im erfolgreichen Nutzungsfalle brauchen würde.

Auch hier verstehe ich leider wieder nicht ganz, was Du damit sagen willst. Was hat bitte der Server (gemeint ist die Maschine, das Blech, nicht das Webserver-Programm) und das Betriebssystem mit dem Web-Request zu tun. Von welchen Sicherheitsabfragen redest Du konkret?
Arduio und der Webserver (gemeint ist das Programm und nicht der Computer) der Bahn reden ja schon miteinander. Diese Strecke der Kommunikation können wir also bei der Analyse erstmal vernachlässigen. Nun würde es ehr darum gehen, zu schauen ob die vom Arduino erzeugten HTTP-Requests RFC-konform sind und daher vom Webserver (Programm nicht Computer) korrekt verarbeitet werden können. Hier ist der Vorschlag von Udo das ganze zum Testen über einen Proxy laufen zu lassen schon mal nicht schlecht.
Da hier ein gewisser Aufwand entsteht, sollten wir dauf das Fedback von "nachtaktiv68" warten, ob die reine GET-Methode klappt, oder ob wir weiter mit der POST Methode testen sollen.

[Reply #18 on:]

Ja also ich habe das jetzt soweit implementiert - mit der GET-Methode funktioniert es einwandfrei, reproduzierbar und stabil. Wobei mich durchaus auch interessieren würde, warum es mit POST nicht funktionieren sollte, denn ein Browser wie Firefox oder Chrome kann es ja auch - warum sollte es dann ein Arduino nicht können, wenn man mal davon ausgeht, dass die Systemressourcen nicht das Problem sind?

[Reply #19 on:]

Ich weiss was du meinst... du willst es doch ohne Tastatureingaben (automatisch) haben, oder ?

[Reply #20 on:]

Ja, es läuft ohne Tastatureingaben ab!

[Reply #21 on:]

Nochmal ... langsam zum mitdenken: Du kommst OHNE Tastatureingaben an den Punkt wo es den Standaort eines gerade in Fahrt befindlichen Zuges anzeigt ? Ich bin BAFF 

[Reply #22 on:]

Sagen wir mal so - ich schicke einen GET-Request, und bekomme als Antwort den Zuglaufplan mit aktuellen Verspätungsdaten, genau das was ich brauche!

Code:

Mit Verspätung:

<tr>

<td class="arrival tqdetail">
16:56
<br />
16:58
</td>

<td class="tqdetail rt top">
<span class="bold red">(+10)</span>
<br />
<span class="bold red">(+10)</span>
</td>

<td class="station tqdetail top">
Mannheim Hbf
<br />
</td>

</tr>



Ohne Verspätung:

<tr>

<td class="arrival tqdetail">
18:41
<br />
18:43
</td>

<td class="tqdetail rt top">
<br />
</td>

<td class="station tqdetail top">
Koblenz Hbf
<br />
</td>

</tr>

[Reply #23 on:]

Oha ! Das wundert mich. Bei der Bahn ist bekanntermaßen nichts unmöglich.

Hast du mal so einen Link mit seinen Paramtern ?

[Reply #24 on:]

Mein Request sieht so aus:

Code:

GET /bin/trainsearch.exe/dox?date=11.02.12&productClassFilter=2&trainname=2311&stationFilter=80&start=Suchen HTTP/1.1
Host: reiseauskunft.bahn.de

Wird halt dynamisch in meinem Sketch erzeugt.

[Reply #25 on:]

Ich bin hin und weg !

Das ist also rein über GET Parameter ansprechbar! Prima Sache !

im Browser: http://reiseauskunft.bahn.de/bin/trainsearch.exe/dox?date=11.02.12&productClassFilter=2&trainname=2311&stationFilter=80&start=Suchen

[Reply #26 on:]

@df6ih: Wozu brauchst Du "Tastatureingaben"? Es ist doch wurscht woher die Daten der Parameter kommen. Da die Werte bekannt sind, werden die beim HTTP-Request in Richtung Webserver der Bahn übertragen. Egal ob per GET oder per POST, die Daten stecken immer in einem Request. Bei GET in der URL, genauer eigentlich URI und beim POST im Body des Request. Die Daten werden doch nicht einzeln übertragen, jedesmal, wenn Du im Formular etwas einträgst oder anklickst. Das geht zwar auch (per AJAX), wird aber im Bahnformular nicht verwendet und war auch nie Gegenstand der Diskussion.
Es gibt auch prinzipiell keinen Unterschied zwischen Deinem Browser und er Arduino-Software. Am Ende schickt ein Programm über eine TCP Verbindung auf Port 80 an die IP 81.200.198.90 einen größeren String, der dann von der Gegenstelle interpretiert wird. Die daraus resultierende Antwort schickt dann der Bahnserver wieder über die gleiche Verbindung zurück.
Spannend bleibt die Frage nach den POST Parametern allemal. Leider ist mein Arduino-Ethernet ziemlich tief in meiner Wetterstation vergraben, daher kann ich das zur Zeit nicht testen. Ich behalte das aber mal im Hinterkopf, denn so offene Fragen zu Sachen die eingentlich funktionieren müßten, mag ich auch nicht.