http post statt get für das Absetzen von Befehlen

[Guest]

Originally posted by: <email address deleted>

FHEM ist von remote via PGM2 praktisch unbenutzbar, da die requests vom Netz
gecached werden. Dies liegt daran, das die Befehle, die Aktionen auslösen sollen,
get-requests sind. Nach HTTP-Spezifikation müssen für solche statusändernden
requests aber post-requests verwendet werden.

Ich habe folgende Fragen:

- Habe ich hier irgendetwas falsch verstanden?

- Ist dies in einer neueren FHEM-Version schon gefixed?

- Wie geht Ihr mit diesem Problem um?

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Die Aussage kann ich nicht nachvollziehen, und ich greife auf meine FHEM-Instanzen per Intra- wie Internet zu. PGM2 läuft an der Stelle problemlos.

Das "das Netz" Requests per se cachen würde, ist ebenfalls eine Beobachtung, die ich nicht bestätigen kann; es dürfte sich um ein lokales Problem handeln, welches auch nur lokal gelöt werden kann.

Das für "statusändernde Requests POST" vorgeschrieben wäre, ist mir neu, aber ich habe auch nie eine "HTTP-Spezifikation" in dem Sinne gelesen. Wäre aber die Neudatenübermittlung per GET untersagt, befände sich FHEM immerhin in guter Gesellschaft. Da GET einfacher umzusetzen ist als POST, würde ich eine Abkehr von GET in PGM2 nicht begrüssen.

Sofern PGM2 Dich nicht zufrieden stellt sei darauf hingewiesen, dass es weitere Frontends für FHEM gibt.

MfG,
-kai

----- Ursprüngliche Mitteilung -----
> FHEM ist von remote via PGM2 praktisch unbenutzbar, da die requests vom
> Netz   gecached werden. Dies liegt daran, das die Befehle, die Aktionen
> auslösen sollen,   get-requests sind. Nach HTTP-Spezifikation müssen für
> solche statusändernden   requests aber post-requests verwendet werden.
>
> Ich habe folgende Fragen:
>
> - Habe ich hier irgendetwas falsch verstanden?
>
> - Ist dies in einer neueren FHEM-Version schon gefixed?
>
> - Wie geht Ihr mit diesem Problem um?

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[rudolfkoenig]

                                                   

> Da GET einfacher umzusetzen ist als POST, würde ich eine Abkehr von GET in
> PGM2 nicht begrüssen.

Evtl. hilft ein korrekt berechnetes "Expires:" Zeile im header.
Aktuell wird das nur fuer "langlebige" Teile (wie .css) verwendet.
Und m.A.n. auch nicht ganz korrekt, komisch dass es funktioniert.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

On 2011-03-23 10:22, Kai 'wusel' Siering wrote:
> Die Aussage kann ich nicht nachvollziehen, und ich greife auf meine FHEM-Instanzen
> per Intra- wie Internet zu. PGM2 läuft an der Stelle problemlos.
>
> Das "das Netz" Requests per se cachen würde, ist ebenfalls eine Beobachtung, die
> ich nicht bestätigen kann;

OK. es ist nicht "das Netz" und es kann ja auch durchaus funktionieren, falls
nicht z.B. Dein Provider irgendwo einen Cache dazwischengeschaltet hat. Manche
Provider tun dies aber und das ist laut RFC2616 auch ausdrücklich OK.


 > es dürfte sich um ein lokales Problem handeln, welches
> auch nur lokal gelöst werden kann.

Nein, es handelt sich eindeutig nicht um ein lokales Problem.


> Das für "statusändernde Requests POST" vorgeschrieben wäre, ist mir neu, aber ich
> habe auch nie eine "HTTP-Spezifikation" in dem Sinne gelesen. Wäre aber die
> Neudatenübermittlung per GET untersagt, befände sich FHEM immerhin in guter
> Gesellschaft.

Man kann statt post auch durchaus put nehmen. Welche Webseiten erlauben denn
Statusänderungen via get? Ich habe wirklich viele Jahre Webportale konzipiert und
ich kenne keinen Fall in dem eine vom User beabsichtigte Statusänderung via get
etwas anderes als ein Fehler oder ein dirty hack gewesen wäre.


Es geht insgesamt auch nicht nur um das cachen. Die usergewollte statusverändernde
Verwendung von get ist einfach nicht vorgesehen und verstößt gegen das
Grundkonzept von HTTP.


Hier ein paar Quellen. Als erste das RFC selbst:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
Hier steht:
"In particular, the convention has been
established that the GET and HEAD
methods SHOULD NOT have the significance
of taking an action other than
retrieval. These methods ought to be
considered "safe". This allows user
agents to represent other methods, such
as POST, PUT and DELETE, in a special
way, so that the user is made aware of
the fact that a possibly unsafe action
is being requested."


Hier noch ein paar andere Stellen:

http://www.w3.org/2001/tag/doc/whenToUseGet-20040321#checklist

http://www.w3.org/2001/tag/doc/whenToUseGet-20040321#safe

http://stackoverflow.com/questions/4273697/what-is-the-difference-between-get-and-post-in-the-context-of-creating-an-ajax-re

http://developer.mindtouch.com/REST/REST_for_the_Rest_of_Us
Hier bei der Beschreibung von get, put und post nachsehen!


Auch wenn Du Dir mal irgendeinen Text zum Thema RESTful HTTP durchliest wirst Du
vergleichbare Aussagen finden.


Gruß
Heiner

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

Hier ein noch besserer Link:

http://www.prozesse-und-systeme.de/servletPRGPattern.html

Gleich der erste Absatz bringt es gut auf den Punkt.



p.s.: Ich hoffe, dieses posting erscheint nur einmal; die Oberfläche
hat geklemmt.

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.

[Guest]

Originally posted by: <email address deleted>

On 03/23/2011 11:02 AM, Heiner Bunjes wrote:
> On 2011-03-23 10:22, Kai 'wusel' Siering wrote:
>> Die Aussage kann ich nicht nachvollziehen, und ich greife auf meine FHEM-Instanzen
>> per Intra- wie Internet zu. PGM2 läuft an der Stelle problemlos.
>>
>> Das "das Netz" Requests per se cachen würde, ist ebenfalls eine Beobachtung, die
>> ich nicht bestätigen kann;
>
> OK. es ist nicht "das Netz" und es kann ja auch durchaus funktionieren, falls nicht z.B. Dein Provider irgendwo einen Cache dazwischengeschaltet hat. Manche Provider tun dies aber und das ist laut RFC2616 auch ausdrücklich OK.

Gut, dann gehört in die PGM2-Antwort ein entsprechender Expires- oder
No-Cache-Header und gut.

>  > es dürfte sich um ein lokales Problem handeln, welches
>> auch nur lokal gelöst werden kann.
>
> Nein, es handelt sich eindeutig nicht um ein lokales Problem.

Nun, es ist jedenfalls weder ein generisches (es ist das erste Mal, daß es
thematisiert wurde in mehreren Jahren) noch globales (ist mir z. B. bislang
nicht als Problem aufgefallen). Daher: eher ein lokales, d. h. auf die Netz-
anbindung des initialen Melders begrenztes/bezogenes, Thema.

>> Das für "statusändernde Requests POST" vorgeschrieben wäre, ist mir neu, aber ich
>> habe auch nie eine "HTTP-Spezifikation" in dem Sinne gelesen. Wäre aber die
>> Neudatenübermittlung per GET untersagt, befände sich FHEM immerhin in guter
>> Gesellschaft.
>
> Man kann statt post auch durchaus put nehmen.

Nunja. Ein http://my.host/cgi-bin/my.cgi?status=foo geht halt extremst simpel,
notfalls per echo|telnet. Keine andere Methode bietet diese Möglichkeit -- und,
ich gebe es gerne zu, von PUT höre ich heute zum ersten Mal Definitionsge-
mäß ist PUT für die Übermittlung von Dateien vorgesehen; das wäe dann ein API-
Rewrite größeren Stils  ...

> Welche Webseiten erlauben denn Statusänderungen via get?

Zum Beispiel Motion (http://www.lavrsen.dk/foswiki/bin/view/Motion/MotionHttpAPI);
eine kurze Suche schmeißt u. a. https://www.hipchat.com/docs/api/method/rooms/message,
http://apidocs.mailchimp.com/ raus, SPHPBLOG macht es mindestens für's Rating von
Beiträgen, ...

... und ein Verbot der Nutzung von GET zu Statusänderungen gibt es nicht, kann nicht
einmal aus 2616 herbeigeredet werden: "the convention has been established that [...]
SHOULD NOT have the significance of taking an action other than retrieval". Wäre es
tatsächlich so, stünde da "MUST", was aber schon mangels entsprechender Festlegung
im HTTP/1.0 definierenden RFC1945 schwierig ist, von den HTTP/0.9 definieenden Do-
kumenten (http://www.w3.org/Protocols/HTTP/HTTP2.html) ganz zu schweigen.

> Es geht insgesamt auch nicht nur um das cachen. Die usergewollte statusverändernde
> Verwendung von get ist einfach nicht vorgesehen und verstößt gegen das Grundkonzept
> von HTTP.

Das sehe ich nicht so. Ich gebe zwar zu, daß "GET" nicht wirklich nach Datenver-
änderung klingt, und habe mich auch in stillen Minuten mal gefragt, warum das
wohl "GET" heißt, aber es ist nun einmal Fakt, daß nur per GET speicherbare, d. h.
einfach wiederholbare URLs realisierbar sind, ein Bookmark "Wohnzimmerlampe an"
geht nicht mit POST oder PUT. Und die initiale Definition sagt sinngemäß "Ziel
einer Datenverbeitung", und das ist ja auch gegeben.

MfG,
         kai

--
Sie haben diese Nachricht erhalten, da Sie der Google Groups-Gruppe FHEM users beigetreten sind.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an fhem-users@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an fhem-users+unsubscribe@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/fhem-users?hl=de, um weitere Optionen zu erhalten.