Wie werden Parameter in einer HTTP POST -Anforderung gesendet?
In einer HTTP GET -Anforderung werden Parameter als - Abfragezeichenfolge gesendet:
http://example.com/pageParameter = Wert & auch = ein anderer
In einer HTTP POST -Anforderung werden die Parameter nicht zusammen mit der URI gesendet.
Wo sind die Werte? Im Anfragekopf? Im Anfragetext? Wie sieht es aus?
Die Werte werden im Anforderungshauptteil in dem vom Inhaltstyp angegebenen Format gesendet.
Normalerweise ist der Inhaltstyp application/x-www-form-urlencoded, daher verwendet der Anforderungshauptteil dasselbe Format wie die Abfragezeichenfolge:
parameter=value&also=another
Wenn Sie einen Datei-Upload im Formular verwenden, verwenden Sie stattdessen die multipart/form-data -Codierung, die ein anderes Format hat. Es ist komplizierter, aber normalerweise muss es dir egal sein, wie es aussieht, also werde ich kein Beispiel zeigen, aber es kann gut sein zu wissen, dass es existiert.
Der Inhalt wird nach den HTTP-Headern eingefügt. Das Format eines HTTP POST besteht darin, die HTTP-Header, gefolgt von einer Leerzeile und dem Anforderungshauptteil, anzugeben. Die Variablen POST werden als Schlüssel-Wert-Paare im Hauptteil gespeichert.
Sie können dies im unformatierten Inhalt eines HTTP-Posts sehen (siehe unten):
POST /path/script.cgi HTTP/1.0
From: [email protected]
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
home=Cosby&favorite+flavor=flies
Sie können dies mit einem Tool wie Fiddler anzeigen, mit dem Sie die unformatierten HTTP-Anforderungs- und -Antwortnutzdaten überwachen können, die über die Leitung gesendet werden.
Kurze Antwort: In POST Anfragen werden Werte im "Hauptteil" der Anfrage gesendet. Bei Webformularen werden sie höchstwahrscheinlich mit dem Medientyp application/x-www-form-urlencoded oder multipart/form-data gesendet. Programmiersprachen oder Frameworks, die für die Bearbeitung von Web-Anfragen entwickelt wurden, erledigen solche Anfragen normalerweise mit "The Right Thing ™" und bieten Ihnen einen einfachen Zugriff auf die leicht dekodierbaren Werte (wie $_REQUEST oder $_POST in PHP , oder cgi.FieldStorage(), flask.request.form in Python).
Lassen Sie uns nun ein wenig abschweifen, um den Unterschied zu verstehen;)
Der Unterschied zwischen GET und POST Anforderungen ist weitgehend semantisch. Sie werden auch unterschiedlich "verwendet", was den Unterschied bei der Übergabe von Werten erklärt.
GET ( relevanter RFC-Abschnitt )
Wenn Sie eine GET -Anforderung ausführen, fragen Sie den Server nach einer oder mehreren Entitäten. Damit der Client das Ergebnis filtern kann, kann er die sogenannte "Abfragezeichenfolge" der URL verwenden. Die Abfragezeichenfolge ist der Teil nach dem ?. Dies ist Teil der RI-Syntax .
Aus der Sicht Ihres Anwendungscodes (der Teil, der empfängt die Anforderung) müssen Sie den URI-Abfrageteil untersuchen, um Zugriff auf diese Werte zu erhalten.
Beachten Sie, dass die Schlüssel und Werte Teil des URI sind. Browser kann die URI-Länge begrenzen. Der HTTP-Standard besagt, dass es keine Begrenzung gibt. Aber zum Zeitpunkt des Schreibens beschränken die meisten Browser do die URIs (ich habe keine spezifischen Werte). GET Anfragen sollten nie verwendet werden, um neue Informationen an den Server zu senden. Vor allem nicht größere Dokumente. Hier sollten Sie POST oder PUT verwenden.
POST ( relevanter RFC-Abschnitt )
Beim Ausführen einer POST -Anforderung sendet der Client tatsächlich ein neues Dokument an den Remote-Host. Eine Abfrage Zeichenfolge ist daher (semantisch) nicht sinnvoll. Deshalb haben Sie in Ihrem Anwendungscode keinen Zugriff darauf.
POST ist etwas komplexer (und way flexibler):
Wenn Sie eine POST -Anforderung erhalten, sollten Sie immer eine "Nutzlast" erwarten, oder in HTTP-Begriffen: a Nachrichtentext . Der Nachrichtentext an sich ist ziemlich nutzlos, da es kein standard (soweit ich das beurteilen kann. Vielleicht application/octet-stream?) Format gibt. Das Body-Format wird durch den Header Content-Type definiert. Wenn Sie ein HTML FORM -Element mit method="POST" verwenden, ist dies normalerweise application/x-www-form-urlencoded. Ein anderer sehr gebräuchlicher Typ ist mehrteilig/Formulardaten , wenn Sie Datei-Uploads verwenden. Aber es könnte sein alles, angefangen von text/plain über application/json bis hin zu einem benutzerdefinierten application/octet-stream.
In jedem Fall sollte bei einer POST -Anforderung mit einem Content-Type, der von der Anwendung nicht verarbeitet werden kann, ein 415 -Statuscode zurückgegeben werden.
Die meisten Programmiersprachen (und/oder Web-Frameworks) bieten eine Möglichkeit, den Nachrichtentext von/nach den gängigsten Typen (wie application/x-www-form-urlencoded, multipart/form-data oder application/json) zu dekodieren/zu kodieren. Das ist also einfach. Benutzerdefinierte Typen erfordern möglicherweise etwas mehr Arbeit.
Bei Verwendung eines Standard-HTML-Formular-codierten Dokuments sollte die Anwendung die folgenden Schritte ausführen:
- Lesen Sie das Feld
Content-Type - Wenn es sich bei dem Wert nicht um einen der unterstützten Medientypen handelt, geben Sie eine Antwort mit dem Statuscode
415zurück - dekodieren Sie andernfalls die Werte aus dem Nachrichtentext.
Wieder werden Sprachen wie PHP oder Web-Frameworks für andere beliebte Sprachen dies wahrscheinlich für Sie erledigen. Die Ausnahme ist der Fehler 415. Kein Framework kann vorhersagen, welche Inhaltstypen Ihre Anwendung unterstützt und/oder nicht unterstützt. Es liegt an dir.
PUT ( relevanter RFC-Abschnitt )
Eine PUT -Anforderung wird genau so behandelt wie eine POST -Anforderung. Der große Unterschied besteht darin, dass der Server mit einer POST -Anforderung entscheiden soll, wie (und wenn überhaupt) eine neue Ressource erstellt werden soll. Historisch gesehen (ab dem mittlerweile veralteten RFC2616 sollte eine neue Ressource als "untergeordnetes" Element der URI erstellt werden, an die die Anforderung gesendet wurde).
Eine PUT -Anforderung soll dagegen eine Ressource genau at dieser URI und mit gena diesem Inhalt "hinterlegen". Nicht mehr und nicht weniger. Die Idee ist, dass client dafür verantwortlich ist, die Ressource complete zu erstellen, bevor "PUTting" ausgeführt wird. Der Server sollte es akzeptieren as-is auf der angegebenen URL.
Folglich wird eine POST -Anforderung normalerweise nicht zum Ersetzen einer vorhandenen Ressource verwendet. Eine PUT -Anforderung kann sowohl create als auch replace ausführen.
Randnotiz
Es gibt auch " Pfadparameter ", mit denen zusätzliche Daten an die Fernbedienung gesendet werden können, diese sind jedoch so selten, dass ich hier nicht auf allzu viele Details eingehen werde. Als Referenz finden Sie hier einen Auszug aus dem RFC:
Abgesehen von Punktsegmenten in hierarchischen Pfaden wird ein Pfadsegment von der generischen Syntax als undurchsichtig betrachtet. URI-erzeugende Anwendungen verwenden häufig die in einem Segment zulässigen reservierten Zeichen, um schemaspezifische oder dereferenzbehandlungsspezifische Unterkomponenten abzugrenzen. Beispielsweise werden die reservierten Semikolon- (";") und Gleichheitszeichen ("=") häufig verwendet, um Parameter und Parameterwerte, die für dieses Segment gelten, abzugrenzen. Das reservierte Komma (",") wird häufig für ähnliche Zwecke verwendet. Beispielsweise könnte ein URI-Produzent ein Segment wie "name; v = 1.1" verwenden, um einen Verweis auf Version 1.1 von "name" anzugeben, während ein anderer möglicherweise ein Segment wie "name, 1.1" verwendet, um dies anzugeben. Parametertypen können durch eine schemaspezifische Semantik definiert werden. In den meisten Fällen ist die Syntax eines Parameters jedoch spezifisch für die Implementierung des Dereferenzierungsalgorithmus für URIs.
Sie können es nicht direkt in die URL-Leiste des Browsers eingeben.
Sie können beispielsweise mit Live HTTP Headers sehen, wie POST Daten im Internet gesendet werden. Das Ergebnis wird ungefähr so sein
http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password
Wo steht
Content-Length: 30
username=zurfyx&pass=password
wird die Post-Werte sein.
Der Standardmedientyp in einer POST Anfrage ist application/x-www-form-urlencoded. Dies ist ein Format zum Codieren von Schlüssel-Wert-Paaren. Die Schlüssel können doppelt vorhanden sein. Jedes Schlüssel-Wert-Paar ist durch ein &-Zeichen und jeder Schlüssel durch ein =-Zeichen von seinem Wert getrennt.
Zum Beispiel:
Name: John Smith
Grade: 19
Wird codiert als:
Name=John+Smith&Grade=19
Dies wird in den Anforderungshauptteil nach den HTTP-Headern eingefügt.
Bei einigen Webservices müssen Sie die angeforderten Daten und Metadaten separat eingeben. Beispielsweise kann eine Remote-Funktion erwarten, dass die signierte Metadatenzeichenfolge in einem URI enthalten ist, während die Daten in einem HTTP-Body bereitgestellt werden.
Die POST -Anforderung kann semantisch folgendermaßen aussehen:
POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)
name id
John G12N
Sarah J87M
Bob N33Y
Dieser Ansatz kombiniert QueryString und Body-Post logisch unter Verwendung eines einzelnen Content-Type, der eine "Parsing-Anweisung" für einen Webserver ist.
Bitte beachten Sie: HTTP/1.1 wird mit dem #32 (Leerzeichen) links und mit #10 (Zeilenvorschub) umbrochen ) auf der rechten Seite.
Formularwerte in HTTP-POSTs werden im Anforderungshauptteil im selben Format wie die Abfragezeichenfolge gesendet.
Weitere Informationen finden Sie in spec .
Zunächst unterscheiden wir zwischen GET und POST
Get: Dies ist die Standardanforderung HTTP, die an den Server gesendet wird und zum Abrufen der Daten vom Server und der Abfragezeichenfolge nach ? in einem URI wird verwendet, um eine eindeutige Ressource abzurufen.
das ist das Format
GET /someweb.asp?data=value HTTP/1.0
hier data=value ist der übergebene Wert der Abfragezeichenfolge.
POST: Es wird verwendet, um Daten sicher an den Server zu senden. Dies ist das Format einer POST -Anforderung
POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename
Warum POST über GET?
In GET wird der Wert, der an die Server gesendet wird, normalerweise an die Basis-URL in der Abfragezeichenfolge angehängt. Dadurch können Ihre Daten gehackt werden (dies war in früheren Tagen ein Problem für Facebook, in dem Ihre Anmeldeinformationen offengelegt wurden) Aus diesem Grund wird POST verwendet, um Daten an den Server zu senden, der Request Body verwendet hat, um Ihre Daten an den Server zu senden, der sicherer ist, weil er Ihre Daten verbirgt und Ihre Daten aus den Feldern abruft. Berechnen Sie die Länge von sie und fügen sie zu header für content-length hinzu, und keine wichtigen Daten werden direkt an URL angehängt
jetzt, da Ihre Anfrage sicher ist, können alle an den Server gesendeten Werte im Request Body gesendet werden, da der Name impliziert, dass er die Daten enthält, die der Benutzer senden möchte (und sie werden im URL Encoded Format gesendet) ) und der Request Headers schützen die Anfrage durch Vergleichen der Werte im Request Body mit dem Request Headers
Im Netzwerkbereich der Google Developer Tools können Sie grundlegende Informationen dazu anzeigen, wie Anforderungen an die Server gestellt werden.
und Sie können Ihrem Request Headers immer weitere Werte hinzufügen, wie Cache-Control, Origin, Accept.