wann POST wann GET

[Kai]

Hallo,
könnt Ihr mir bitte helfen, wann ich beim CGI
method=POST oder method=GET nehme?

ich verstehe den unterschied nicht ganz.

bin am grübeln wegen formmail, bzw. meinem (baldigen) forum, bzw shop

Danke an Alle

Gruss
Kai

[MudGuard]

Hi,

könnt Ihr mir bitte helfen, wann ich beim CGI
method=POST oder method=GET nehme?

Wann immer möglich POST, und GET nur, wenn es nicht anders geht.

GET: Daten werden an die Url angehängt
POST: die Daten werden "unsichtbar" (im body des http-Request) versendet.

Außerdem: bei GET gibt es (theoretisch zwar nicht, aber praktisch) eine Begrenzung der Menge, die je nach beteiligten Browsern/Server im Bereich einiger weniger Kilobyte liegt.

cu,
Andreas

[Dirk Dorweiler]

Hi!

Wann immer möglich POST, und GET nur, wenn es nicht anders geht.

das ist (sorry)käse. dass die daten per get an die url weitergegeben
werden ist ein vorteil, kein nachteil. denn nur so kann ein
etwaiges ergebnis deines formulars auch einfach per link weitergeben
werden.

gegen "get" spricht eigentlich nur die grössenbeschränkung, die mudguard erwähnt hat.

für dein forum, bzw. shop wird diese beschränkung allerdings
kaum zum tragen kommen.

grüsse, dirk.

[MudGuard]

Hi,

Wann immer möglich POST, und GET nur, wenn es nicht anders geht.
das ist (sorry)käse. dass die daten per get an die url weitergegeben
werden ist ein vorteil, kein nachteil.
denn nur so kann ein
etwaiges ergebnis deines formulars auch einfach per link weitergeben
werden.

"und GET nur, wenn es nicht anders geht".
Bei einem Link geht es nicht anders.

Ich sehe also nicht, inwiefern das Käse ist.

cu,
Andreas

[Herbalizer]

Hi!

das ist (sorry)käse. dass die daten per get an die url weitergegeben
werden ist ein vorteil, kein nachteil. denn nur so kann ein
etwaiges ergebnis deines formulars auch einfach per link weitergeben
werden.

Was man auch als Nachteil werten kann. Denn wer will schon, das vertraulichere Daten in der URL für jeder man sicht- und speicherbar übertragen werden.

Gruß Herbalizer

[Andreas Thaler]

Mickysoft meint dazu:

SUMMARY
Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters, with a maximum path length of 2,048 characters. This limit applies to both POST and GET request URLs.

If you are using the GET method, you are limited to a maximum of 2,048 characters (minus the number of characters in the actual path, of course).

POST, however, is not limited by the size of the URL for submitting name/value pairs, because they are transferred in the header and not the URL.

RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, does not specify any requirement for URL length.

[Alexander Foken]

Moin Moin !

W3C meint sinngemäß: GET, wenn ein und der selbe Request immer wieder inhaltlich das selbe Ergebnis liefert, und POST, wenn sich der Status des Servers/CGIs ändert. Eine GET-URL sollte reload-fähig sein und eigentlich keine Seiteneffekte haben. Ideal z.B. für die Forumsansicht hier, der Inhalt bleibt der selbe (von neuen Postings mal abgesehen), Seiteneffekte gibt es nicht (außer in </my/>, wo besuchte Postings markiert werden). POST ändert das "Innenleben" des Servers, z.B. bei neuen Postings, die auf dem Server in die DB geschrieben werden.

Kurz: GET liest, POST schreibt.

GET-URLs sollten nicht länger als etwa 1000 Zeichen sein, weil einige Browser, Proxies und Server sonst irgendwann durcheinander kommen. Auch wenn in den HTTP-RFCs steht, daß es für URLs keine Längenbegrenzung geben darf.

Das gilt natürlich auch für POST-URLs, aber beim POST-Request werden die Daten außerhalb der URL übertragen.

Alexander

[Mathias Bigge]

Hi Kai,

die Kontroverse über POST und GET finde ich interessant, aber auch etwas kurzsichtig. Ich bin nicht der große HTTP-Experte, aber ein paar Aspekte wage ich doch einmal aus meiner Sicht anzusprechen. Vielleicht ergänzt oder korrigiert mich mal einer von den Experten...

1. Illusionen über die Sicherheit von POST

Da jeder DAU per GET versandte Informationen lesen und ändern kann, halten einige Entwickler POST prinzipiell für sicherer. Aber auch mit POST übergebene Daten sind mit mäßigem Aufwand manipulierbar.

2. Unterschiede

Bei POST lässt sich eine versehentliche Wiederholung eines Requests besser, wenn auch nicht zuverlässig vermeiden. Normalerweise sollte man GET vor allem für Aufrufe verwenden, bei denen keine Daten auf dem Server verändert werden, so dass der mehrfache Aufruf der gleichen Ressource keine unangenehmen Effekte erzeugt. Oft werden GET-Requests benutzt, wenn ein Caching erwünscht ist.

3. Begegnungen von POST und GET

Erhält ein POST-Request eine 301 (Moved Permanently) oder 303 (See Other) Status-Antowrt und damit eine neue Location, kann, im zweiten Fall sollte ein automatischer Wechsel von POST nach GET erfolgen. Insofern sollte ein CGI-Script in den meisten Fällen beide Requesttypen verarbeiten können.

POST-Requests können auch an URLs übergeben werden, die einen Query-String enthalten, so dass man eventuell auf beide Datenquellen zugreifen will oder muss.

Viele Grüße
Mathias Bigge

[Andreas Korthaus]

Hi Mathias!

3. Begegnungen von POST und GET

Erhält ein POST-Request eine 301 (Moved Permanently) oder 303 (See Other) Status-Antowrt und damit eine neue Location, kann, im zweiten Fall sollte ein automatischer Wechsel von POST nach GET erfolgen. Insofern sollte ein CGI-Script in den meisten Fällen beide Requesttypen verarbeiten können.

? Aber es werden doch nicht die POST Variablen in GET Variablen umgewandelt, oder? Wäre mir zumindest neue also bringt es dem Script auch nichts beides zu verarbeiten, oder?

Grüße
Andreas

[Mathias Bigge]

Hi Andreas Korthaus,

? Aber es werden doch nicht die POST Variablen in GET Variablen umgewandelt, oder? Wäre mir zumindest neue also bringt es dem Script auch nichts beides zu verarbeiten, oder?

Hm, die Variableninhalte sind die gleichen aber natürlich ist der Zugriff auf Variablen, die per GET übertragen wurden ein anderer als der auf Variablen die per POST übertragen wurden, zumindest in Perl. Regelt das PHP irgendwie selbsttätig?

Viele Grüße
Mathias Bigge

[Andreas Korthaus]

Hallo Mathias

? Aber es werden doch nicht die POST Variablen in GET Variablen umgewandelt, oder? Wäre mir zumindest neue also bringt es dem Script auch nichts beides zu verarbeiten, oder?

Hm, die Variableninhalte sind die gleichen aber natürlich ist der Zugriff auf Variablen, die per GET übertragen wurden ein anderer als der auf Variablen die per POST übertragen wurden, zumindest in Perl. Regelt das PHP irgendwie selbsttätig?

Früher konnte man in PHP diekekt auf Variablen zugreifen, also

script.php?var=123

dann konnte man im Script direkt $var verwenden, print($var) ergab sofort "123", ohen das man die Variable irgendwie importieren mußte. War eine große Sicherheitslücke wenn das unbedarft eingestzt wurde.
In den Aktuellen PHP-Versionen erfogt der Zugriff über supergobale Arrays, die automatisch dem Script zur Verfügung gestellt werden, die dann überall verwendet werden können.

$_POST enthält alle Daten per POST,
$_GET alle per GET,
$_COOKIES alle per Cookie.

Hieße also

print($_GET['var']);

Dann gibt es noch einen Array wo nicht nach diesen 3 Herkunftsmöglichkeiten unterschieden wird:

$_REQUEST,

es ginge also auch:

print($_REQUEST['var']);

das würde dann auch funktionieren wenn var per POST übermittelt worden wäre, $_GET halt nicht.

Zurück zum Problem, ich bin mir selbst nicht sicher, ich denke dass das Problem eher auf der Client-Seite liegt. Wenn der Browser nach einem Request einen Redirection-Header bekommt - was passiert dann im Client? Ich weiß es ehrlich gesagt nicht. Ich würde aber vermuten, dass entweder ein neuer POST-Request an die neue Recource gesendet wird, das fänd ich am logischsten, und sonst, wenn es denn eine GET-Request gibt würde ich schätzen das die Variablen unter den Tisch fallen, was ich aber nicht glaube. Nur das die Variablen(sorry, Parameter ;-)) dann in einen GET-Request übersetzt werden fänd ich unlogisch. Was passiert bei einem anderen POST-Modus als form-urlencode?

Naja ich weiß es nicht.

Grüße
Andreas

PS: nur _falls_ es Dich interessiert: http://www.php3.de/manual/en/language.variables.predefined.php ;-)

[Christian Seiler]

Hallo Mathias,

Da jeder DAU per GET versandte Informationen lesen und ändern kann, halten einige Entwickler POST prinzipiell für sicherer. Aber auch mit POST übergebene Daten sind mit mäßigem Aufwand manipulierbar.

ACK.

Bei POST lässt sich eine versehentliche Wiederholung eines Requests besser, wenn auch nicht zuverlässig vermeiden. Normalerweise sollte man GET vor allem für Aufrufe verwenden, bei denen keine Daten auf dem Server verändert werden, so dass der mehrfache Aufruf der gleichen Ressource keine unangenehmen Effekte erzeugt. Oft werden GET-Requests benutzt, wenn ein Caching erwünscht ist.

ACK. ;-)

Erhält ein POST-Request eine 301 (Moved Permanently) oder 303 (See Other) Status-Antowrt und damit eine neue Location, kann, im zweiten Fall sollte ein automatischer Wechsel von POST nach GET erfolgen. Insofern sollte ein CGI-Script in den meisten Fällen beide Requesttypen verarbeiten können.

Du meinst 302 (Found) anstelle von 301 (Moved Permanently) oder? Naja, POST + 30x-Header ist ja sowieso ein Kapitel für sich, Björn Höhrmann hat mir mal mit diesem Link geantwortet: http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html (ein Punkt, wo der IE sogar besser HTTP kann als der Mozilla - waaaah!)

POST-Requests können auch an URLs übergeben werden, die einen Query-String enthalten, so dass man eventuell auf beide Datenquellen zugreifen will oder muss.

Korrekt. ;-)

Christian