[LUGA] Mit freundlicher Unterstützung von:
Linux New Media AG

Mail Thread Index


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: [luga] Interessanter Effekt mit POST Daten...



On Fri, 2006-07-14 at 11:15 +0200, Roland Schwarz wrote:
> Bernd Petrovitsch wrote:
> > On Thu, 2006-07-13 at 13:05 +0200, Peter Buzanits wrote:
> > [...]
> >> Da manche Seitenaufrufe nur dann Sinn machen, wenn POST-Daten
> >> mitgeschickt werden, würde es mich sehr wundern, wenn es ein Feature
> >> gäbe, dass den gleichen Request nochmal macht, dabei aber die POST
> >> Daten weglässt.
> > 
> > Noch dazu kann ein POST-Request den Zustand der Applikation verändern
> > (im Gegensatz zum GET-Request, der das nicht macht).
> > Deshalb fragen die Browser beim POST und nicht beim GET.
> 
> ?? Applikation ???

Ja, das was sich auf der anderen Seite vom GET/POST-Request befindet.

> Versteh ich nicht. Wenn Applikation in dem Sinne gemeint ist, daß eine 
> Applikation "State" enthält, dann hat das überhaupt nichts mit unserer 

So ist es gemeint. Und es hat damit zu tun, weil die Requests halt so
definiert sind

> Frage zu tun. http is stateless. Punkt.

http ist nur ein Transportprotokoll und ist als solches stateless. Das
trifft noch keine Aussage über die die Applikation einen Level höher,
die ja auch mehrere stateless http requests machen kann und selber
stateful ist (ich würde sogar meinen, daß die überwältigender Mehrheit
der Webapps auch sind - akut fällt mir auch keine andere ein).

> Wenn es um CGI scripts geht können natürlich sowohl GET als auch POST 
> den Zustand einer allfälligen "Applikation" verändern. Das kann im 

Natürlich können sie den verändern. Aber ob das ein Feature oder Bug
ist, ist eine andere Frage.

> Prinzip auch schon ein einfacher Aufruf einer HTML Seite. z.b.: Aufruf 
> wird mitgezählt, aka. logfile -> "Application: Data Retention" hat 
> Zustand verändert.

Ja. Aber "konkret" ist der Unterschied die Änderungen, die für den
Client relevant sind (und das sind Logzeilen o.ä. idR nicht). Die
Beschreibung von obigen Link ist zwangsläufig auch nicht konketer, weil
man es für jede Applikation entscheiden muß, ob die Aktion idempotent
ist (z.B. eine Datensatz anschauen) unddeshalb ein GET-Request OK ist
oder nicht (z.B. einen Datensatz einfügen oder löschen) und deshalb -
streng nach Protokolldefinition - ein POST-Request verwendet werden muß.

> Genaugenommen passiert in beiden Fällen exakt das Gleiche: Um eine Seite 
> anzufordern müssen
> a) der Link bestimmt sein, und
> b) alle POST Daten übermittelt werden.
> 
> Warum die Browser nur bei reload von Seiten mit POST Daten fragen, und
> nicht auch wenn ?bla=fasel&baaz=foo im Link erscheint kann ich mir nur
> so erklären, daß im zweiten Fall der Anwender die Daten im Link schon 
> vorher sieht, und bei den POST Daten etwas Unsichtbares gesendet würde.

Wenn sie kurz genug sind, ja.

Potentiell sind Argumente im Body des POST-Requests.
Das Gegenargument ist: Warum zeigen dann die Browser diese Argumente
nicht her?
Ist ja ziemlich sinnlos, nach der Bestätigung zu fragen, *weil* es die
Argumente gibt und sie nicht herzuzeigen. Und was ist wenn es gar keien
gibt?

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
September 2010