Frage Wie werden Parameter in einer HTTP POST-Anfrage gesendet?


In einem HTTP BEKOMMEN Anfrage, Parameter werden als gesendet Abfragezeichenfolge:

http://beispiel.com/seite? Parameter = Wert & auch = ein anderer

In einem HTTP POST Anfrage werden die Parameter nicht zusammen mit dem URI gesendet.

Wo sind die Werte? In der Anfrage Kopfzeile? Im Anfragetext? Wie sieht es aus?


1165
2018-01-27 19:19


Ursprung


Antworten:


Die Werte werden im Anfragetext in dem Format gesendet, das der Inhaltstyp angibt.

Normalerweise ist der Inhaltstyp application/x-www-form-urlencoded, daher verwendet der Anfragetext das gleiche Format wie die Abfragezeichenfolge:

parameter=value&also=another

Wenn Sie einen Datei-Upload im Formular verwenden, verwenden Sie den multipart/form-data Codierung stattdessen, die ein anderes Format hat. Es ist komplizierter, aber Sie müssen sich normalerweise nicht darum kümmern, wie es aussieht, also werde ich kein Beispiel zeigen, aber es kann gut sein zu wissen, dass es existiert.


962
2018-01-27 19:32



Der Inhalt wird nach den HTTP-Headern eingefügt. Das Format eines HTTP-POST besteht aus den HTTP-Headern, gefolgt von einer leeren Zeile gefolgt vom Anfragetext. Die POST-Variablen werden im Körper als Schlüssel-Wert-Paare gespeichert.

Sie können dies im unformatierten Inhalt eines HTTP-Posts sehen, der unten gezeigt wird:

POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
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 Werkzeug wie sehen Geiger, mit dem Sie die rohen HTTP-Request- und Response-Payloads überwachen können, die über die Verbindung gesendet werden.


349
2018-01-27 19:21



Kurze Antwort: Bei POST-Anfragen werden Werte im "body" der Anfrage gesendet. Bei Webformularen werden sie höchstwahrscheinlich mit einem Medientyp von gesendet application/x-www-form-urlencoded oder multipart/form-data. Programmiersprachen oder Frameworks, die speziell für die Bearbeitung von Web-Anfragen entwickelt wurden, machen bei solchen Anfragen normalerweise "The Right Thing" und bieten Ihnen einen einfachen Zugang zu den leicht entschlüsselten Werten (wie z $_REQUEST oder $_POST in PHP oder cgi.FieldStorage(), flask.request.form in Python).


Lassen Sie uns nun ein wenig abschweifen, was den Unterschied erklären könnte;)

Der Unterschied zwischen GET und POST Anfragen sind weitgehend semantisch. Sie werden auch unterschiedlich "benutzt", was den Unterschied in der Art und Weise erklärt, wie Werte weitergegeben werden.

BEKOMMEN (relevanten RFC-Abschnitt)

Bei der Ausführung von a GET Bitte fragen Sie den Server nach einem oder mehreren Entitäten. Damit der Client das Ergebnis filtern kann, kann er die so genannte "Abfragezeichenfolge" der URL verwenden. Die Abfragezeichenfolge ist der Teil nach dem ?. Dies ist Teil der URI-Syntax.

Also, aus der Sicht Ihrer Anwendung Code (der Teil, der empfängt die Anfrage), müssen Sie den URI-Abfrageteil überprüfen, um auf diese Werte zugreifen zu können.

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 dieses Schreibens, die meisten Browser machen Begrenzen Sie die URIs (ich habe keine spezifischen Werte). GET Anfragen sollten noch nie verwendet werden, um neue Informationen an den Server zu senden. Vor allem nicht größere Dokumente. Dort sollten Sie verwenden POST oder PUT.

POST (relevanten RFC-Abschnitt)

Bei der Ausführung von a POST Anfrage, der Client sendet tatsächlich eine neue Dokument zum entfernten Host. Also, a Abfrage String macht (semantisch) keinen Sinn. Aus diesem Grund haben Sie im Anwendungscode keinen Zugriff darauf.

POST ist ein bisschen komplexer (und Weg flexibler):

Wenn Sie eine POST-Anfrage erhalten, sollten Sie immer eine "Payload" erwarten, oder, in HTTP-Termini: a Nachrichtentext. Der Nachrichtentext an sich ist ziemlich nutzlos, da es keinen gibt Standard (Soweit ich das beurteilen kann. Vielleicht Anwendung / Oktett-Stream?) Format. Das Körperformat wird durch die definiert Content-Type Header. Bei Verwendung eines HTML FORM Element mit method="POST"Das ist normalerweise application/x-www-form-urlencoded. Eine andere sehr häufige Art ist Multipart / Formulardaten wenn Sie Datei-Uploads verwenden. Aber könnte sein etwas, von text/plain, Über application/json oder sogar eine Gewohnheit application/octet-stream.

In jedem Fall, wenn a POST Anfrage wird mit einem gemacht Content-Type was nicht von der Anwendung gehandhabt werden kann, sollte a zurückgeben 415 Statuscode.

Die meisten Programmiersprachen (und / oder Web-Frameworks) bieten eine Möglichkeit, den Nachrichtentext von / zu den gebräuchlichsten Typen (wie application/x-www-form-urlencoded, multipart/form-data oder application/json). Das ist einfach. Benutzerdefinierte Typen erfordern möglicherweise etwas mehr Arbeit.

Unter Verwendung eines standardmäßigen HTML-Formular-codierten Dokuments als Beispiel sollte die Anwendung die folgenden Schritte ausführen:

  1. Lies das Content-Type Feld
  2. Wenn der Wert keiner der unterstützten Medientypen ist, geben Sie eine Antwort mit a zurück 415 Statuscode
  3. Andernfalls decodieren Sie die Werte aus dem Nachrichtentext.

Auch Sprachen wie PHP oder Web-Frameworks für andere gängige Sprachen werden das wahrscheinlich für Sie erledigen. Die Ausnahme ist die 415 Error. Kein Framework kann vorhersagen, welche Inhaltstypen von Ihrer Anwendung unterstützt und / oder nicht unterstützt werden. Es liegt an dir.

STELLEN (relevanten RFC-Abschnitt)

EIN PUT Anfrage wird ziemlich genau wie eine behandelt POST anfordern. Der große Unterschied ist, dass a POST Anfrage soll den Server entscheiden lassen, wie (und wenn überhaupt) eine neue Ressource erstellt werden soll. Historisch (von der jetzt veralteten RFC2616 war es eine neue Ressource als "untergeordnetes" (Kind) der URI, wo die Anfrage gesendet wurde) zu erstellen.

EIN PUT Anfrage dagegen soll eine Ressource genau "hinterlegen" beim diese URI und mit genau dieser Inhalt. Nicht mehr und nicht weniger. Die Idee ist, dass die Klient ist verantwortlich für die Herstellung der Komplett Ressource, bevor Sie es "putten". Der Server sollte es akzeptieren wie es ist auf der angegebenen URL.

Als eine Folge, a POST Anfrage ist normalerweise nicht gewohnt ersetzen eine vorhandene Ressource. EIN PUT Anfrage kann beides erstellen und ersetzen.

Randnotiz

Es gibt auch "Pfadparameter"das kann verwendet werden, um zusätzliche Daten an die Fernbedienung zu senden, aber sie sind so ungewöhnlich, dass ich hier nicht zu sehr ins Detail gehen werde. Aber, als Referenz, hier ist ein Auszug aus dem RFC:

Abgesehen von Punktsegmenten in hierarchischen Pfaden wird ein Pfadsegment betrachtet   undurchsichtig durch die generische Syntax. URI-produzierende Anwendungen verwenden häufig die   reservierte Zeichen, die in einem Segment zulässig sind, um schemaspezifisch oder abgrenzen zu können   Dereferenzierungshandler-spezifische Unterkomponenten. Zum Beispiel das Semikolon (";")   und equals ("=") reservierte Zeichen werden oft zum Abgrenzen von Parametern und verwendet   Parameterwerte, die für dieses Segment gelten. Das Komma (",") reserviert   Charakter wird oft für ähnliche Zwecke verwendet. Zum Beispiel ein URI-Produzent   könnte ein Segment wie "name; v = 1.1" verwenden, um einen Verweis auf die Version anzugeben   1.1 von "name", während ein anderer ein Segment wie "name, 1.1" verwenden könnte   Zeige dasselbe an. Parametertypen können schemaspezifisch definiert werden   Semantik, aber in den meisten Fällen ist die Syntax eines Parameters spezifisch für die   Implementierung des URIs Dereferenzierungsalgorithmus.


287
2017-11-03 15:54



Sie können es nicht direkt in die URL-Leiste des Browsers eingeben.

Sie können sehen, wie POST-Daten mit dem Internet gesendet werden Live HTTP Header beispielsweise. 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

werden die post-Werte sein.


48
2018-01-27 19:29



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 dupliziert werden. Jedes Schlüssel-Wert-Paar ist durch ein getrennt & Zeichen, und jeder Schlüssel ist von seinem Wert durch ein getrennt = Charakter.

Beispielsweise:

Name: John Smith
Grade: 19

Ist codiert als:

Name=John+Smith&Grade=19

Dies wird nach den HTTP-Headern im Anforderungshauptteil platziert.


18
2018-06-16 05:33



Formularwerte in HTTP POSTs werden im Anfragetext im selben Format wie der Querystring gesendet.

Weitere Informationen finden Sie unter Spez.


13
2018-01-27 19:20



Einige der Webservices erfordern, dass Sie eine Anfrage stellen Daten und Metadaten separat. Beispielsweise kann eine Remote-Funktion erwarten, dass die signierte Metadaten-Zeichenfolge in einem URI enthalten ist, während die Daten in einem HTTP-Body veröffentlicht werden.

Die POST-Anfrage kann semantisch wie folgt 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 mit einem einzigen Content-Type Das ist eine "Parsing-Anweisung" für einen Webserver.

Bitte beachten Sie: HTTP / 1.1 ist eingewickelt mit dem #32 (Raum) auf der linken Seite und mit #10 (Zeilenvorschub) rechts.


13
2017-07-31 14:01



Vor allem wollen wir unterscheiden zwischen GET und POST 

Bekommen: Es ist die Standardeinstellung HTTP Anfrage, die an den Server gestellt wird und zum Abrufen der Daten vom Server und der darauffolgenden Abfrage verwendet wird ? 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 Query-String-Wert übergeben.

POST: Es wird verwendet, um Daten sicher an den Server zu senden, also alles, was benötigt wird, das ist das Format von a POST anfordern

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?

Im GET Der an die Server gesendete Wert wird normalerweise an die Basis-URL in der Abfragezeichenfolge angehängt. Dadurch können Ihre Daten gehackt werden (dies war in den letzten Tagen ein Problem für Facebook, auf dem Ihre Anmeldeinformationen veröffentlicht wurden) POSTwird verwendet, um Daten an den verwendeten Server zu senden Request Body um Ihre Daten an den Server zu senden, der sicherer ist, weil es Ihre Daten verbirgt, und es Ihre Daten aus den Feldern erhält, berechnen Sie die Länge von ihnen und fügen Sie sie dem hinzu header zum content-length und keine wichtigen Daten werden direkt an die URL

Jetzt, da Ihre Anfrage gesichert ist, können alle Werte, die an den Server gesendet werden, in der Request Body Wie der Name schon sagt, wird es die Daten enthalten, die der Benutzer senden wollte (und es wird in der URL Encoded Format) und die Request Headers wird die Anfrage durch Vergleichen der Werte in der Request Body mit dem Request Headers

Im Abschnitt Netzwerk der Google Developer Tools können Sie grundlegende Informationen darüber anzeigen, wie Anforderungen an die Server gestellt werden.

und Sie können immer mehr Werte in Ihrem hinzufügen Request Headers mögen Cache-Control , Origin , Accept.


0
2017-07-19 07:04