nicht angemeldet dedlfix
dedlfix
Der Martin
dedlfix
Der Martin
Der Martin
dedlfix
Ich will mit 'GET' eine URL vergeben lassen ('http://www.domain.de/member.php?name=htmlprofi' oder sowas).
Mit 'POST' möchte ich dann den inhalt übertragen.
Ich habe es schon versucht, aber der browser hat dann entweder 'GET' oder 'POST' oder gar nichts ausgeführt. Mein Einfall war so:
<form action="member.php" method="get">
Name<br />
<input type="text" size="17" name="Name" /><br />
<form action="member.php" method="post">
Alter<br />
<input type="text" size="17" name="Alter" /><br />
<center>
<input type="submit" value="OK">
</center>
</form>
Kann mir jemand Helfen?
PS: Wenn jemand dann so eine URL mittels get generieren lässt, wie kann ich den Link automatisch in eine Liste einfügen lassen? Zum Beispiel eine Liste mit den Mitgliedern.
Danke für alle Antworten.
Kann mir jemand Helfen?
Das action-Attribut des form-Elements kennst du ja schon.
PS: Wenn jemand dann so eine URL mittels get generieren lässt, wie kann ich den Link automatisch in eine Liste einfügen lassen? Zum Beispiel eine Liste mit den Mitgliedern.
Sinnvollerweise mit einer Serverseitigen logik die dann "irgendwas" damit macht. In eine Datenbank oder ein Textfile schreiben z.B.
Kann mir jemand Helfen?
Das action-Attribut des form-Elements kennst du ja schon.
Ja. Nur was soll ich damit machen, dass mein Problem gelöst wird..?
PS: Wenn jemand dann so eine URL mittels get generieren lässt, wie kann ich den Link automatisch in eine Liste einfügen lassen? Zum Beispiel eine Liste mit den Mitgliedern.
Sinnvollerweise mit einer Serverseitigen logik die dann "irgendwas" damit macht. In eine Datenbank oder ein Textfile schreiben z.B.
Und wie geht das?
Danke
DumDiDum33
Das action-Attribut des form-Elements kennst du ja schon.
Ja. Nur was soll ich damit machen, dass mein Problem gelöst wird..?
Im action-Attribut kannst du einen URL notieren - der darf eine Hostnamen, einen Pfad, ein Fragment und auch einen Querystring enthalten. Auch wenn du als Methode POST nutzt.
Sinnvollerweise mit einer Serverseitigen logik die dann "irgendwas" damit macht. In eine Datenbank oder ein Textfile schreiben z.B.
Und wie geht das?
Dafür gibts Möglichkeiten wie Sand am Meer. Prinzipiell wertet der Server deinen Request aus, verarbeitet ihn und tut dann damit irgendwas. Eben in ein Textfile (z.B. CSV) speichern. Danach arbeitet das Script weiter (oder ein ganz anders, durch einen späteren Aufruf) und liest dieses, macht irgendetwas (z.B. das CSV-File auslesen und in eine HTML-Tabelle umwandeln) und schickt sie dann an den Client.
Hi,
Ich will mit 'GET' eine URL vergeben lassen ('http://www.domain.de/member.php?name=htmlprofi' oder sowas).
Mit 'POST' möchte ich dann den inhalt übertragen.
Ich habe es schon versucht, aber der browser hat dann entweder 'GET' oder 'POST' oder gar nichts ausgeführt. Mein Einfall war so:
<form action="member.php" method="post">
Und wo bitte hast du hier jetzt den Querystring angegeben?
PS: Wenn jemand dann so eine URL mittels get generieren lässt, wie kann ich den Link automatisch in eine Liste einfügen lassen? Zum Beispiel eine Liste mit den Mitgliedern.
Keine Ahnung, was du meinst. Bitte beschreibe verständlicher, was du wissen willst.
MfG ChrisB
Hi,
Ich will mit 'GET' eine URL vergeben lassen ('http://www.domain.de/member.php?name=htmlprofi' oder sowas).
was verstehst Du unter "vergeben lassen"?
Ich habe es schon versucht, aber der browser hat dann entweder 'GET' oder 'POST' oder gar nichts ausgeführt. Mein Einfall war so:
Formulare können nicht geschachtelt werden. Egal welche Logik Du auf eine solche Schachtelungen anwenden willst, es gibt andere Logiken, die hierzu inkompatibel sind, aber exakt die selbe Legitimität besitzen.
PS: Wenn jemand dann so eine URL mittels get generieren lässt, wie kann ich den Link automatisch in eine Liste einfügen lassen? Zum Beispiel eine Liste mit den Mitgliedern.
Öhm, vielleicht beschreibst Du erst mal, was für Vorgänge Du hier überhaupt vermutest und gerne hättest. URLs werden nicht generiert, sondern aufgerufen und gegebenenfalls beantwortet.
Cheatah
hi,
Get und post innerhalb von einem Request schließen sich aus. Entweder Oder. Zum Verständnis der Parameterübermittlung:
ein Klick auf den Button mit name="zitrone" value="klick" type="submit"
führt mit form method="GET" zu einer URI {SCRIPT_NAME}?zitrone=klick das könntest Du genausogut als Link irgendwo hinschreiben. Bei einem POST hingegen wird der URI nicht geändert.
Hotte
Bei einem POST hingegen wird der URI nicht geändert.
Ja, ich weiß, nur genau das soll es ja. :D Und ich möchte auch noch post darin haben, damit die url dann nicht so lang ist und damit längere texte darin übermittelt werden können.
Danke
DumDiDum23
Hi!
Ja, ich weiß, nur genau das soll es ja. :D Und ich möchte auch noch post darin haben, damit die url dann nicht so lang ist und damit längere texte darin übermittelt werden können.
Warum eigentlich? Gibt's nen Grund, ncihtinfach post zu benutzen und gut?
Bei einem POST hingegen wird der URI nicht geändert.
Ja, ich weiß, nur genau das soll es ja. :D Und ich möchte auch noch post darin haben, damit die url dann nicht so lang ist und damit längere texte darin übermittelt werden können.
Keiner hindert Dich daran, Deine URIs so zusammenzubauen, wie Du das für richtig hältst, nur ein POST auf einen URI like
http://example.com/php?brief=kurztext;attr=male
wird sich nicht in einen GET verwandeln. Das muss klar sein ;-)
Horst Hagebau
Hi!
Keiner hindert Dich daran, Deine URIs so zusammenzubauen, wie Du das für richtig hältst, nur ein POST auf einen URI like
http://example.com/php?brief=kurztext;attr=male
wird sich nicht in einen GET verwandeln. Das muss klar sein ;-)
Das ist ja vermutlich auch nicht gefordert. Abgesehen davon, dass der OP noch recht wenig Erfahrung in Webdingen hat, eher unsinnig herumprobiert als zielstrebig etwas zu lernen und die Begriffe nicht so verwendet, wie das ein Fachman tut, will er wahrscheinlich nur trotz POST-Requests Werte im $_GET-Array von PHP haben. Wenn PHP dieses Array $QUERY_STRING genannt hätte, wäre es auch weniger missverständlich, wenn man den Q.S. meint, aber GET dazu sagt.
Lo!
hi,
[..] will er wahrscheinlich nur trotz POST-Requests Werte im $_GET-Array von PHP haben. Wenn PHP dieses Array $QUERY_STRING genannt hätte, wäre es auch weniger missverständlich, wenn man den Q.S. meint, aber GET dazu sagt.
Tja, GET-Parameter werden auch üblicherweise aus dem QUERY_STRING gelesen, das ist in Perl auch so (Modul CGI.pm). 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.
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 ;-)
Horst Hecketeck
Hi!
[..] will er wahrscheinlich nur trotz POST-Requests Werte im $_GET-Array von PHP haben. Wenn PHP dieses Array $QUERY_STRING genannt hätte, wäre es auch weniger missverständlich, wenn man den Q.S. meint, aber GET dazu sagt.
Tja, GET-Parameter werden auch üblicherweise aus dem QUERY_STRING gelesen, das ist in Perl auch so (Modul CGI.pm).
Und das ist eben der Irrtum oder die Fehlimplementation in Perl und PHP. Es sind keine GET-Parameter, sondern wie gesagt "Query-String-Parameter". Denn diese GET-/Querystring-Parameter lassen sind in jedem Request unterbringen, also auch beispielsweise HEAD, weil sie Bestandteil der URL sind und die braucht es schließlich für jeden Typ von Request. GET ist ein typischer Anwendungsfall für Daten im Query-String, und als Variablennamen schön kurz (QS wäre es auch, ist aber weniger verständlich), aber eben nicht der einzige.
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? 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.
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.
Warum sollte er?
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.
Wenn im POST der Formularinhalt übertragen wird, der einen zu bearbeitenden Datensatz darstellt, so ist es eventuell ungünstig, dahinein noch Metadaten zu bringen, die vielleicht einen Benennungskonflikt ergeben. Dazu ein Beispiel, doch vorab: GET und Querystring nimmt man günstigerweise für das Abfragen von Information, also eine bestimmte URL (inklusive Querystring) sollte stets die gleiche Antwort liefern. Für serverseitige Datenveränderung sollte man GET nicht verwenden. Für den Fall ist POST besser geeignet. Ein POST-Request erzeugt also irgendeine Form von Veränderung auf dem Server. (Deswegen fragen Client in der Regel nach, wenn ein POST noch einmal wiederholt werden soll.) Dies ist nur eine allgemeine Richtlinie. Gründe, anders zu verfahren, wird es sicherlich geben.
Nun das Beispiel: Dargestellt wird eine Tabelle mit Datensätzen. Diese kann zum Beispiel durch Klick auf die Spaltenüberschriften sortiert werden. Diese Information, nach welcher Spalte sortiert werden soll, überträgt man praktischerweise als Query-Parameter, denn es wird nur anders dargestellt aber nichts verändert. Ein Automat (Suchmaschinenspider) kann diese URLs gefahrlos aufrufen. Der zweite Teil der Seite zeigt ein Formular an, mit dem man einen Datensatz (vielleicht einer aus obiger Tabelle) bearbeiten kann. Nun möchte ich aber durch das Absenden des Formulars nicht die Sortierinformation der Tabelle verlieren. Wie überträgt man also beides? Baut man die Sortierinformation als Hidden-Fields in den POST-Request ein, stören sie eventuell bei der Weiterverarbeitung des geänderten Datensatzes. Sie als URL-Bestandteil zu übertragen, da wo sie beim Spaltenkopf-Link-Click sowieso schon übertragen werden, sehe ich als besser geeignet an. Sie sind also immer da, egal bei welchem Request-Typ. (Dieses Beispiel ignoriert der Einfachheit halber Plausibilitätsprüfungen auf Serverseite, bei der zum Beispiel Feldnamen gegen eine Liste der erwarteten Namen geprüft werden.)
Insgesamt gibt es 4 Wege, Information in einem Request zu übertragen:
Diese Möglichkeiten sind da, also kann man sich auch sinnvoll nutzen. Und das Gute daran: sie sind alle gleichzeitig nutzbar. (POST-Daten sind natürlich an einen POST-Request gebunden.)
Lo!
Hallo,
Und das ist eben der Irrtum oder die Fehlimplementation in Perl und PHP. Es sind keine GET-Parameter, sondern wie gesagt "Query-String-Parameter". Denn diese GET-/Querystring-Parameter lassen sind in jedem Request unterbringen, also auch beispielsweise HEAD, weil sie Bestandteil der URL sind
... und deswegen heißen sie treffenderweise auch URL-Parameter.
Wenn im POST der Formularinhalt übertragen wird, der einen zu bearbeitenden Datensatz darstellt, so ist es eventuell ungünstig, dahinein noch Metadaten zu bringen, die vielleicht einen Benennungskonflikt ergeben. Dazu ein Beispiel, doch vorab: GET und Querystring nimmt man günstigerweise für das Abfragen von Information, also eine bestimmte URL (inklusive Querystring) sollte stets die gleiche Antwort liefern. Für serverseitige Datenveränderung sollte man GET nicht verwenden. Für den Fall ist POST besser geeignet. Ein POST-Request erzeugt also irgendeine Form von Veränderung auf dem Server.
So ähnlich habe ich das auch schon mal formuliert, nur kürzer. :-)
Insgesamt gibt es 4 Wege, Information in einem Request zu übertragen:
- Querystring
- POST-Daten
- Cookie
- PathInfo, beziehungsweise der Pfadanteil in der URL allgemein
Diese Möglichkeiten sind da, also kann man sich auch sinnvoll nutzen. Und das Gute daran: sie sind alle gleichzeitig nutzbar. (POST-Daten sind natürlich an einen POST-Request gebunden.)
Richtig, wobei die Möglichkeit, Daten per Cookie zu übertragen, am wenigsten transparent für den Nutzer ist, während PathInfo und/oder Query String am offensichtlichsten sind.
So long,
Martin
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
... müsste aber das Modul mit eigenen Routinen nachbilden. Das ist wirklich sehr aufwändig.
Nur Teile desselben. Und es ist auch nicht schwierig. Zumal man etwas, das in Perl ja eh notwendig ist, wenn man -T verwenden will, in diesen Vorgang gleich einbeziehen kann.
mfg Beat
Hallo,
... müsste aber das Modul mit eigenen Routinen nachbilden. Das ist wirklich sehr aufwändig.
Nur Teile desselben. Und es ist auch nicht schwierig.
Die Analysieren und Aufbereiten eines Mediatyps multipart/form-data halte nicht für trivial, und die Rede war vom Aufwand.
Gruß aus Berlin!
eddi
... müsste aber das Modul mit eigenen Routinen nachbilden. Das ist wirklich sehr aufwändig.
Nur Teile desselben. Und es ist auch nicht schwierig.
Die Analysieren und Aufbereiten eines Mediatyps multipart/form-data halte nicht für trivial, und die Rede war vom Aufwand.
Bei Fileupload rate ich zum Modul, zweifelsfrei.
mfg Beat
hi,
Die Analysieren und Aufbereiten eines Mediatyps multipart/form-data halte nicht für trivial, und die Rede war vom Aufwand.
Bei Fileupload rate ich zum Modul, zweifelsfrei.
Genau. Nachdem ein POST konstatiert und STDIN geparst wurde, brauchen wir ja nur den GET-Parser hinterherzuschieben und setzen dazu $ENV{REQUEST_METHOD} rotzfrech auf GET.
Hotti ;-)
Hi!
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.
Das "warum" bezog sich auf den zweiten Teil. Auch habe ich beim Überfliegen der CGI-Spezifikation nicht die Stelle gefunden, die eine Auswertung des Request-Typs vorsieht, um daraufhin nur eine Datenquelle zu berücksichtigen. Oder meintest du etwas anderes?
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.
PHP stellt von sich die Daten in $_POST und $_GET ($_FILES ignorier ich jetzt mal) bereit, ohne dass man etwas dafür unternehmen muss. Welche Funktionalität genau meinst du, stelle PHP nicht bereit? Zumindest gibt es da die Funktion parse_str(), die auf den Querystring und auf die POST-Daten anwendbar ist, wenn man das aus welchem Grund auch immer (zusätzlich) von Hand braucht.
Lo!
Re:
Das "warum" bezog sich auf den zweiten Teil. Auch habe ich beim Überfliegen der CGI-Spezifikation nicht die Stelle gefunden, die eine Auswertung des Request-Typs vorsieht, um daraufhin nur eine Datenquelle zu berücksichtigen. Oder meintest du etwas anderes?
ok
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.
PHP stellt von sich die Daten in $_POST und $_GET ($_FILES ignorier ich jetzt mal) bereit, ohne dass man etwas dafür unternehmen muss. Welche Funktionalität genau meinst du, stelle PHP nicht bereit?
Die Superglobals, genau. Das ist aber mein Anliegen. Einfaches Beispiel: Ich will einen Request selbst entgegennehmen, weil ich einen Progress zur Anzeige bringen will. PHP nimmt, wie Du ja selbst schreibst alles entgegen, dann erst wird das Script abgearbeitet. Für mein Beispiel muss aber erst Scriptcode ausgeführt werden, mit dem der Request entgegengenommen wird. Bis jetzt habe ich mir so geholfen, statt eines CGI-Binärs ein CLI zu nehmen. Es ist nicht wirklich komfortabel und Möglichkeiten wie FastCGI werden erst mit den Namensräumen bereit gestehen. Somit werden potentielle Vorteile, weil hochgeladene Dateien nicht hin- und herkopiert werden müssen, derzeit zunichte gemacht.
Gruß aus Berlin!
eddi
Hi!
Einfaches Beispiel: Ich will einen Request selbst entgegennehmen, weil ich einen Progress zur Anzeige bringen will. PHP nimmt, wie Du ja selbst schreibst alles entgegen, dann erst wird das Script abgearbeitet.
Das ist in der Tat mit im Webserver betriebenen PHP-out-of-the-box nicht möglich. Doch irgendwann in der 5er Serie wurden Hooks eingebaut, die zumindest das Schreiben einer PECL-Erweiterung ermöglichen, die in diesem "frühen Stadium" des Requests bereits tätig werden kann. Soweit ich mich erinnere, ist eine solche Verwendung des Upload-Hooks in APC eingebaut.
Lo!
Re:
Das ist in der Tat mit im Webserver betriebenen PHP-out-of-the-box nicht möglich. Doch irgendwann in der 5er Serie wurden Hooks eingebaut, die zumindest das Schreiben einer PECL-Erweiterung ermöglichen, die in diesem "frühen Stadium" des Requests bereits tätig werden kann. Soweit ich mich erinnere, ist eine solche Verwendung des Upload-Hooks in APC eingebaut.
BTW: Läuft APC jetzt endlich auch unter 5.3?
Gruß aus Berlin!
eddi
Hi!
BTW: Läuft APC jetzt endlich auch unter 5.3?
Dazu folgende Chat-Konversation:
[...]
[22:20] dedlfix: mal was anderes. läuft apc (mittlerweile) unter php 5.3? (http://forum.de.selfhtml.org/my/?t=191352&m=1276310)
[22:22] globe: APC funktioniert nirgends ;)
[22:24] dedlfix: ok, und im ernst?
[22:25] globe: ich hab php5.3 laufen und APC am start
[22:25] globe: also.. geladen
[22:25] globe: ich bekomme keine fehler
Lo!
Re:
BTW: Läuft APC jetzt endlich auch unter 5.3?
[22:25] globe: ich bekomme keine fehler
Danke. (Also habe ich eine Nebenbeschäftigung.. ;)
Gruß aus Berlin!
eddi
hi,
Warum nicht, was spricht denn dagegen, Information auf verschiedenen Wegen zu übermitteln? Und was ist daran Arbeit?
Es spricht überhaupt nichts dagegen, den QS auch bei einem POST zu verwenden. Die zusätzliche Arbeit ergibt sich jedoch aus der Tatsache, dass die üblichen Parser (CGI.pm in Perl) bei einem POST den QS ignorieren (hab ich gestern abend schon geschrieben); so muss ich mir den Parser eben umschreiben (hab ich gestern abend schon geschrieben).
So. Nochmal erkläre ich das nicht.
Schönen Tag,
Hotte
Hi!
Warum nicht, was spricht denn dagegen, Information auf verschiedenen Wegen zu übermitteln? Und was ist daran Arbeit?
Es spricht überhaupt nichts dagegen, den QS auch bei einem POST zu verwenden. Die zusätzliche Arbeit ergibt sich jedoch aus der Tatsache, dass die üblichen Parser (CGI.pm in Perl) bei einem POST den QS ignorieren (hab ich gestern abend schon geschrieben); so muss ich mir den Parser eben umschreiben (hab ich gestern abend schon geschrieben).
Das ist aber dann ein Perl- oder genauer ein CGI.pm-Problem und kein generelles, so wie ich deine Aussage deutete. PHP beispielsweise kennt diese Einschränkung und damit den Mehraufwand nicht. Das füllt $_GET und $_POST so wie Daten vorhanden sind und nicht abhängig vom Request-Typ. Deine "generelle Empfehlung" beruht also nur auf einem Unvermögen von CGI.pm.
Lo!
hi,
Das ist aber dann ein Perl- oder genauer ein CGI.pm-Problem und kein generelles, so wie ich deine Aussage deutete. PHP beispielsweise kennt diese Einschränkung und damit den Mehraufwand nicht. Das füllt $_GET und $_POST so wie Daten vorhanden sind und nicht abhängig vom Request-Typ. Deine "generelle Empfehlung" beruht also nur auf einem Unvermögen von CGI.pm.
Ja das ist ja mal interessant, danke für die Info!
Btw., das bei einem POST auch Parameter im QUERY_STRING stehen können wissen wir nun ;-)
Frage: Können bei einem GET auch Parameter in STDIN vorhanden sein?
Ich glaube, die Antwort zu kennen, möchte jedoch das Publikum nicht beeinflussen.
Hotti Hottentott
Hallo,
Frage: Können bei einem GET auch Parameter in STDIN vorhanden sein?
Theoretisch ja, wenn der Client sich nicht an die Spielregeln hält.
Ein GET- oder HEAD-Request hat normalerweise keine "Nutzlast", Content-Length sollte 0 sein. Natürlich könnte ein Client einen GET-Request absetzen, die Header brav mit einer Leerzeile beenden und dann noch einen Haufen Nutzdaten hinterherschieben.
Ein CGI, das die Eingangsdaten selbst verarbeitet, so wie du es mit deinem Perl-Script tust, kann diese Nutzdaten möglicherweise sogar lesen und verarbeiten - ich bin mir aber nicht sicher, könnte mir auch vorstellen, dass der Apache diesen Request Body gleich abweist.
Ich glaube, die Antwort zu kennen, möchte jedoch das Publikum nicht beeinflussen.
Gemein! Dann gib wenigstens irgendwann später auch deine Version zum Besten.
Ciao,
Martin
hi,
Ich glaube, die Antwort zu kennen, möchte jedoch das Publikum nicht beeinflussen.
Gemein! Dann gib wenigstens irgendwann später auch deine Version zum Besten.
Ok, die Zeit ist reif dafür (hab dedlfix und Beats Statements gelesen) ;-)
Ich denke, nein, es gibt bei einem GET nix aus STDIN zu lesen. Und in der Praxis hab ich auch noch keinen Bedarf daran gehabt, bei einem POST den QUERY_STRING (QS) zu parsen, weil: was ich da reinschreiben könnte, kann ich auch woanders unterbringen, beispielsweise in einem hidden-Field.
Denkbar jedoch wäre auch für mich, im QS eine Information zu verstecken, beispielsweise den Zeitstempel für den Zeitpunkt der Erstellung eines Formulars, wobei ich dazu auf das hidden-Field verzichte. Das dürfte zumindest einen notorischen SPAMer verwirren, zumal meine Zeitstempel nicht auf den ersten Blick als solche erkennbar sind (Stichwort pack(), base64).
Horst Haselhuhn
Mahlzeit,
Ich denke, nein, es gibt bei einem GET nix aus STDIN zu lesen.
na gut, auch dedlfix und Beat konnten die Frage ja nicht zweifelsfrei beantworten (dass man "sowas nicht macht", ist klar). Vielleicht probiere ich bei Gelegenheit mal aus, was wirklich passiert.
Und in der Praxis hab ich auch noch keinen Bedarf daran gehabt, bei einem POST den QUERY_STRING (QS) zu parsen
Nun, was heißt "Bedarf" ... Ich hab das jedenfalls schon ein paarmal gemacht, also ein POST-Formular erstellt, und zusätzlich URL-Parameter im action-Attribut. Ist vielleicht unkonventionell, ich sehe darin aber nichts Anstößiges oder gar Problematisches.
Denkbar jedoch wäre auch für mich, im QS eine Information zu verstecken, beispielsweise den Zeitstempel für den Zeitpunkt der Erstellung eines Formulars, wobei ich dazu auf das hidden-Field verzichte.
Und dann dürftest du dieses Formular nur mit einem selbstgebauten Client abschicken, denn normale Browser würden dir 'ne lange Nase zeigen. ;-)
Das dürfte zumindest einen notorischen SPAMer verwirren, zumal meine Zeitstempel nicht auf den ersten Blick als solche erkennbar sind (Stichwort pack(), base64).
Äh, ja - und wer könnte dann das betreffende Formular noch benutzen?
Ciao,
Martin
hi,
Denkbar jedoch wäre auch für mich, im QS eine Information zu verstecken, beispielsweise den Zeitstempel für den Zeitpunkt der Erstellung eines Formulars, wobei ich dazu auf das hidden-Field verzichte.
Und dann dürftest du dieses Formular nur mit einem selbstgebauten Client abschicken, denn normale Browser würden dir 'ne lange Nase zeigen. ;-)
Achwas, das geht mit aldi, guck ma:
<form action="/cgi-bin/feedback.cgi?1234" method="POST">
Hotti
Hi,
Und dann dürftest du dieses Formular nur mit einem selbstgebauten Client abschicken, denn normale Browser würden dir 'ne lange Nase zeigen. ;-)
Achwas, das geht mit aldi, guck ma:
<form action="/cgi-bin/feedback.cgi?1234" method="POST">
offensichtlich haben wir uns hier missverstanden. Was du hier vorstellst, ist ein POST-Request, der zusätzlich URL-Parameter enthält. Dass das geht, ist ja schon seit Urzeiten klar.
Wir sprachen doch hier von einem GET-Request, der abweichend vom Standard zusätzlich einen Request-Body überträgt.
So long,
Martin
immer diese Missverständnisse,
Wir sprachen doch hier von einem GET-Request, der abweichend vom Standard zusätzlich einen Request-Body überträgt.
Da wüsste ich auch nicht, wie ich das hinkriege...
Aber der Trick mit $ENV{REQUEST_METHOD} verbiegen und dann den Parser erneut aufzurufen, funktioniert schonmal ;-)
Hotti
Und in der Praxis hab ich auch noch keinen Bedarf daran gehabt, bei einem POST den QUERY_STRING (QS) zu parsen, weil: was ich da reinschreiben könnte, kann ich auch woanders unterbringen, beispielsweise in einem hidden-Field.
Es gibt einen trivialen und alltäglichen Bedarf für QS Information auch bei POST Requests: Bei Url Rewriting.
mfg Beat
Und in der Praxis hab ich auch noch keinen Bedarf daran gehabt, bei einem POST den QUERY_STRING (QS) zu parsen, weil: was ich da reinschreiben könnte, kann ich auch woanders unterbringen, beispielsweise in einem hidden-Field.
Szenario: User soll ne Datei hochladen können und ich möchte ihm eine Fortschrittsleiste für den Uploadfortschritt anbieten. Um den Upload an meine Fortschrittsleiste zu binden, möchte ich gerne eine ID mitgeben. Packe ich die in ein input type="hidden", habe ich ein Problem:
Ich muss anfangen, SDTIN zu lesen, damit lese ich aber leider auch schon den Upload ein. Das will ich aber noch nicht, weil ich ja erst mein Statusverarbeitungszeugs anhand der ID machen will...
BTW: CGI.pm(andere dito) kennt einen Hybridmodus(noch nicht benutzt, das sagt aber die Doku), um bei nem POST auch an die URL Parms zu kommen, eigenes Query-String parsen also nicht nötig.
hi,
BTW: CGI.pm(andere dito) kennt einen Hybridmodus(noch nicht benutzt, das sagt aber die Doku), um bei nem POST auch an die URL Parms zu kommen, eigenes Query-String parsen also nicht nötig.
Auf die Schnelle:
$the_string = $query->query_string; # $query means CGI-Object
Hotti
Auf die Schnelle:
$the_string = $query->query_string; # $query means CGI-Object
Wenn ich jetzt noch wüsste, was Du mir damit sagen willst? Du erwähntest doch den Zusatzaufwand und die Doku sacht "brauchste nit", ergo der Hinweis.
Auf die Schnelle:
$the_string = $query->query_string; # $query means CGI-ObjectWenn ich jetzt noch wüsste, was Du mir damit sagen willst? Du erwähntest doch den Zusatzaufwand und die Doku sacht "brauchste nit", ergo der Hinweis.
Achwas, nach ich im serverseitigen CGI den POST geparst habe, setze ich einfach
$ENV{REQUEST_METHOD} = "GET";
und rufe CGI::param() erneut auf, dann hab ich alles.
Damit bin ich auch schneller fertig, als die DOKU zu lesen.
Hotti
Hi!
Btw., das bei einem POST auch Parameter im QUERY_STRING stehen können wissen wir nun ;-)
Frage: Können bei einem GET auch Parameter in STDIN vorhanden sein?
Danke für die Herausforderung, aber es gelang mir nicht, sie zu lösen. Mein Verstand sagt mir, dass GET leer sein sollte, aber was sagt die Vorschrift?
RFC 2616 ist zuständig für HTTP/1.1. In Section 4.3 steht der Satz
A message-body MUST NOT be included in
a request if the specification of the request method (section 5.1.1)
does not allow sending an entity-body in requests.
Der Unterschied zwischen entity-body und message-body ist meines Erachtens für den Fall vernachlässigbar.
Section 5.1.1 erzählt nichts weiter zum Message-Body, verweist aber für GET auf Section 9.3. Die schweigt sich in Bezug auf dem Message-Body ebenfalls aus. Sollte das die Antwort sein? "must not … if … not allow(ed)" heißt es, aber da steht nichts, also auch keine Erlaubnis.
The GET method means retrieve whatever information (in the form of an
entity) is identified by the Request-URI.
Dieser Satz steht unter anderem da, jedoch hat "means" keine regulative Kraft. Ich sehe den Satz lediglich als Erläuterung und nicht als Erfüllung des MUST NOT an. Gegenprobe bei POST:
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line.
Da interpretiere ich zumindest, dass POST verwendet wird, ein im Request eingeschlossenes entity serverseitig zu verarbeiten. Hmmm, auch keine direkte Erlaubnis.
Lo!
Ergo reduziert es sich auf die Frage, ob ein Server bei Method=GET dennoch einen unerwarteten requestbody in die Umgebungsvariable schreibt.
Dass reguläre Clients[1] bei GET einen Requestbody nachschieben, schliesse ich mal aus.
Bei Apache als Server müsste man halt den Test machen.
[1] Was da in der Wildbahn rumtummelt, mal ausgenommen.
mfg Beat
Ergo reduziert es sich auf die Frage, ob ein Server bei Method=GET dennoch einen unerwarteten requestbody in die Umgebungsvariable schreibt. Dass reguläre Clients[1] bei GET einen Requestbody nachschieben, schliesse ich mal aus. Bei Apache als Server müsste man halt den Test machen.
Also folgendes:
Apache nimmt bei GET ein request body nur dann an, wenn ein Content-Length-Header die Anfrage begleitet. Dagegen quittiert lighttpd jede GET-Anfrage mit Status 400. Generell ist aber anzumerken, dass Geschichten wie XML-RPC oder SOAP von POST ausgehen. Das entspricht ja auch soweit der Interpretation von RFC 2616; 9.5.
Gruß aus Berlin!
eddi
Hallo,
Apache nimmt bei GET ein request body nur dann an, wenn ein Content-Length-Header die Anfrage begleitet. Dagegen quittiert lighttpd jede GET-Anfrage mit Status 400.
das heißt doch schon: Unabhängig davon, ob GET mit Request Body sinnvoll oder regelkonform ist, kann man nicht von einer Unterstützung bei allen Servern ausgehen. Wer's benutzen will, sollte also sehr genau wissen, was er tut.
Ciao,
Martin
Hi,
Get und post innerhalb von einem Request schließen sich aus. Entweder Oder.
Jein.
Einen Querystring in der Zieladresse zu nutzen, ist auch bei POST möglich.
MfG ChrisB
hi,
Einen Querystring in der Zieladresse zu nutzen, ist auch bei POST möglich.
Richtig. Aber ein POST auf einen URI like 'http://example.com/xy?123' ist eben ein POST und kein GET.
Horst von der Post