nicht angemeldet
Hallo Dedlfix,
Bei einem POST hingegen werden die Parameter aus STDIN gelesen. Die üblichen Parser haben daher eine Kontrollstruktur, wo erstmal geguckt wird, was der UserAgent gemacht hat, POST oder GET.
Warum?
das hängt mit der CGI Spezifikation zusammen.
Ich wüsste nicht, was es bringt, den Request-Typ als (ausschließendes) Unterscheidungsmerkmal zu verwenden. Die URL ist in jedem Fall vorhanden und damit die Möglichkeit des Query-Strings. Es müsste lediglich auf POST getestet werden, um (zusätzlich) den Body des Requests auszuwerten.
Allerdings.
Aber wenn ich will, kann ich mich über das "Übliche" erheben und auch bei einem POST auf der Serverseite die Parameter aus dem QUERY_STRING parsen, denn der wird bei einem POST nicht verändert.
Das ist jedoch nicht unbedingt ne Sache, die ich empfehle. Wozu auch, macht nur zusätzliche Arbeit ;-)Warum nicht, was spricht denn dagegen, Information auf verschiedenen Wegen zu übermitteln? Und was ist daran Arbeit? Information, die ich brauche, muss ich irgendwie übertragen, und da ist es vom Arbeitsaufwand her egal, wo ich sie übertrage. Es kann sich aber für eine bestimmte Aufgabenstellung als Vorteil erweisen, getrennte Übertragungswege für unterschiedliche Informationen zu verwenden.
Das Gefühl beschleicht mich, Ihr missversteht Euch. Für gewöhnlich nimmt man ja, wie Rolf schon sagte, das CGI-Modul Perls, was den Request für das eigentliche Programm erschließt. Ich verstehe ihn nun so, dass er mit -erheben über das Übliche- meint, dieses Modul nicht zu nutzen. Man hätte somit volle Kontrolle über alles, müsste aber das Modul mit eigenen Routinen nachbilden. Das ist wirklich sehr aufwändig. PHP bietet diese Möglichkeiten bspw. von sich aus schlichtweg gar nicht an, was ich sehr schade finde.
Gruß aus Berlin!
eddi
Der Martin