In een HTTP GET-verzoek worden parameters verzonden als een querystring:
http://example.com/page?parameter=value&also=another
In een HTTP POST-verzoek worden de parameters niet samen met de URI verzonden.
Waar zijn de waarden? In de verzoekkop? In de aanvraaginstantie? Hoe ziet het eruit?
Antwoord 1, autoriteit 100%
De waarden worden verzonden in de hoofdtekst van het verzoek, in het formaat dat het inhoudstype specificeert.
Meestal is het inhoudstype application/x-www-form-urlencoded, dus de hoofdtekst van het verzoek gebruikt hetzelfde formaat als de queryreeks:
parameter=value&also=another
Als je een bestandsupload in het formulier gebruikt, gebruik je in plaats daarvan de multipart/form-data-codering, die een ander formaat heeft. Het is ingewikkelder, maar het maakt je meestal niet uit hoe het eruit ziet, dus ik zal geen voorbeeld laten zien, maar het kan goed zijn om te weten dat het bestaat.
Antwoord 2, autoriteit 33%
De inhoud wordt achter de HTTP-headers geplaatst. Het formaat van een HTTP POST is om de HTTP-headers te hebben, gevolgd door een lege regel, gevolgd door de hoofdtekst van de aanvraag. De POST-variabelen worden opgeslagen als sleutel-waardeparen in de hoofdtekst.
Je kunt dit zien in de onbewerkte inhoud van een HTTP-bericht, hieronder weergegeven:
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
Je kunt dit zien met behulp van een tool zoals Fiddler, die je kunt gebruiken om de onbewerkte HTTP-verzoeken en responspayloads te bekijken die over de draad.
Antwoord 3, autoriteit 31%
Kort antwoord: in POST-verzoeken worden waarden verzonden in de “body” van het verzoek. Bij webformulieren worden ze hoogstwaarschijnlijk verzonden met het mediatype application/x-www-form-urlencoded of multipart/form-data. Programmeertalen of frameworks die zijn ontworpen om webverzoeken af te handelen, doen meestal “The Right Thing ” met dergelijke verzoeken en bieden u gemakkelijke toegang tot de gemakkelijk gedecodeerde waarden (zoals $_REQUEST of $_POST in PHP, of cgi.FieldStorage(), flask.request.form in Python).
Laten we nu een beetje afdwalen, dat kan helpen om het verschil te begrijpen 😉
Het verschil tussen GET– en POST-verzoeken is grotendeels semantisch. Ze worden ook anders “gebruikt”, wat het verschil verklaart in de manier waarop waarden worden doorgegeven.
GET (relevante RFC-sectie)
Bij het uitvoeren van een GET-verzoek, vraagt u de server om één of een reeks entiteiten. Om de klant in staat te stellen het resultaat te filteren, kan hij de zogenaamde “query string” van de URL gebruiken. De querystring is het deel na de ?. Dit maakt deel uit van de URI-syntaxis.
Dus vanuit het oogpunt van uw applicatiecode (het deel dat het verzoek ontvangt), moet u het URI-querygedeelte inspecteren om toegang te krijgen tot deze waarden.
Houd er rekening mee dat de sleutels en waarden deel uitmaken van de URI. Browsers kunnen een limiet stellen aan de lengte van de URI. De HTTP-standaard stelt dat er geen limiet is. Maar op het moment van schrijven beperken de meeste browsers de URI’s wel (ik heb geen specifieke waarden). GET-verzoeken mogen nooit worden gebruikt om nieuwe informatie naar de server te verzenden. Zeker geen grotere documenten. Dat is waar je POST of PUT moet gebruiken.
POST (relevante RFC-sectie)
Bij het uitvoeren van een POST-verzoek, dient de client feitelijk een nieuw document in bij de externe host. Dus een query string is (semantisch) niet logisch. Daarom heb je er geen toegang toe in je sollicitatiecode.
POST is iets complexer (en veel flexibeler):
Als je een POST-verzoek ontvangt, moet je altijd een “payload” verwachten, of, in HTTP-termen: een berichttekst. De berichttekst zelf is vrij nutteloos, aangezien er geen standaard (voor zover ik weet. Misschien applicatie/octet-stream?) formaat is. De body-indeling wordt gedefinieerd door de kop Content-Type. Bij gebruik van een HTML FORM element met method="POST", is dit meestal application/x-www-form-urlencoded. Een ander veel voorkomend type is multipart/form-data als je bestandsuploads gebruikt. Maar het kan alles zijn, variërend van text/plain, over application/json of zelfs een aangepaste application/octet-stream.
In elk geval, als een POST-verzoek wordt gedaan met een Content-Type dat niet kan worden verwerkt door de applicatie, moet het een 415 statuscode.
De meeste programmeertalen (en/of web-frameworks) bieden een manier om de berichttekst te decoderen/coderen van/naar de meest voorkomende typen (zoals application/x-www-form-urlencoded, multipart/form-data of application/json). Dus dat is makkelijk. Aangepaste typen vereisen mogelijk wat meer werk.
Met een standaard HTML-formulier gecodeerd document als voorbeeld, zou de toepassing de volgende stappen moeten uitvoeren:
- Lees het veld
Content-Type - Als de waarde niet een van de ondersteunde mediatypen is, retourneer dan een reactie met een
415statuscode - Decodeer anders de waarden uit de berichttekst.
Nogmaals, talen zoals PHP of web-frameworks voor andere populaire talen zullen dit waarschijnlijk voor je regelen. De uitzondering hierop is de 415-fout. Geen enkel framework kan voorspellen welke content-types uw applicatie wel en/of niet ondersteunt. Dit is aan jou.
PUT (relevante RFC-sectie)
Een PUT-verzoek wordt ongeveer op exact dezelfde manier afgehandeld als een POST-verzoek. Het grote verschil is dat een POST-verzoek de server moet laten beslissen hoe (en als dat al gebeurt) een nieuwe bron aan te maken. Historisch gezien (vanaf de nu verouderde RFC2616 was het om een nieuwe bron te creëren als een “ondergeschikte” (onderliggende) van de URI waar het verzoek naartoe werd gestuurd).
Een PUT-verzoek daarentegen wordt verondersteld een bron precies op die URI te “deponeren”, en met precies die inhoud. Niet meer niet minder. Het idee is dat de klant verantwoordelijk is om de complete bron te maken voordat deze wordt “PUT”. De server moet het as-is accepteren op de opgegeven URL.
Als gevolg hiervan wordt een POST-verzoek meestal niet gebruikt om een bestaande bron te vervangen. Een PUT-verzoek kan zowel en vervangen.
Kanttekening
Er zijn ook “padparameters” die kunnen worden gebruikt om aanvullende gegevens naar de afstandsbediening, maar ze zijn zo ongewoon, dat ik hier niet te veel in detail zal treden. Maar ter referentie, hier is een fragment uit de RFC:
Afgezien van puntsegmenten in hiërarchische paden, wordt een padsegment beschouwd
ondoorzichtig door de generieke syntaxis. URI-producerende toepassingen gebruiken vaak de
gereserveerde tekens toegestaan in een segment om schema-specifiek af te bakenen of
dereferentie-handler-specifieke subcomponenten. Bijvoorbeeld de puntkomma (“;”)
en is gelijk aan (“=”) gereserveerde tekens worden vaak gebruikt om parameters af te bakenen en
parameterwaarden die van toepassing zijn op dat segment. De komma (“,”) gereserveerd
karakter wordt vaak voor soortgelijke doeleinden gebruikt. Bijvoorbeeld één URI-producent
kan een segment zoals “name;v=1.1” gebruiken om een verwijzing naar versie aan te geven
1.1 van “naam”, terwijl een ander een segment zoals “naam,1.1” zou kunnen gebruiken om
hetzelfde aangeven. Parametertypes kunnen worden gedefinieerd door schemaspecifiek
semantiek, maar in de meeste gevallen is de syntaxis van een parameter specifiek
aan de implementatie van het URI’s dereferentie-algoritme.
Antwoord 4, autoriteit 5%
Je kunt het niet rechtstreeks in de browser-URL-balk typen.
U kunt zien hoe POST-gegevens op internet worden verzonden met Live HTTP-headers bijvoorbeeld.
Het resultaat zal zoiets zijn
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
Waar staat
Content-Length: 30
username=zurfyx&pass=password
zijn de postwaarden.
Antwoord 5, autoriteit 2%
Het standaard mediatype in een POST-verzoek is application/x-www-form-urlencoded. Dit is een indeling voor het coderen van sleutel-waardeparen. De sleutels kunnen dubbel zijn. Elk sleutel/waarde-paar wordt gescheiden door een teken & en elke sleutel wordt gescheiden van zijn waarde door een teken =.
Bijvoorbeeld:
Name: John Smith
Grade: 19
Is gecodeerd als:
Name=John+Smith&Grade=19
Dit wordt in de hoofdtekst van het verzoek geplaatst na de HTTP-headers.
Antwoord 6
Voor sommige webservices moet u gegevens en metagegevens afzonderlijk plaatsen. Een externe functie kan bijvoorbeeld verwachten dat de ondertekende metadata-string is opgenomen in een URI, terwijl de data in een HTTP-body wordt gepost.
Het POST-verzoek kan er semantisch als volgt uitzien:
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
Deze aanpak combineert logischerwijs QueryString en Body-Post met behulp van een enkel Content-Type wat een “parsing-instructie” is voor een webserver.
Let op: HTTP/1.1 is omhuld met de #32 (spatie) aan de linkerkant en met #10 (regelinvoer) aan de rechterkant.
Antwoord 7
Formulierwaarden in HTTP POST’s worden verzonden in de hoofdtekst van het verzoek, in hetzelfde formaat als de querystring.
Zie voor meer informatie de specificatie.
Antwoord 8
Laten we eerst een onderscheid maken tussen GET en POST
Get: dit is het standaard HTTP-verzoek dat aan de server wordt gedaan en wordt gebruikt om de gegevens op te halen van de server en de queryreeks die na ? in een URI wordt gebruikt om een unieke bron op te halen.
dit is het formaat
GET /someweb.asp?data=value HTTP/1.0
hier data=value is de waarde van de queryreeks die is doorgegeven.
POST: het wordt gebruikt om gegevens veilig naar de server te verzenden, dus alles wat nodig is, dit is het formaat van een POST-verzoek
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
Waarom POST boven GET?
In GET wordt de waarde die naar de servers wordt verzonden meestal toegevoegd aan de basis-URL in de queryreeks, nu zijn er 2 gevolgen hiervan
- De
GET-verzoeken worden met de parameters in de browsergeschiedenis opgeslagen. Uw wachtwoorden blijven dus onversleuteld in de browsergeschiedenis. Dit was vroeger een echt probleem voor Facebook. - Meestal hebben servers een limiet voor hoe lang een
URImag zijn. Als er te veel parameters worden verzonden, ontvangt u mogelijk414 Error - URI too long
In het geval van een postverzoek worden uw gegevens uit de velden in plaats daarvan aan de body toegevoegd. De lengte van de verzoekparameters wordt berekend en toegevoegd aan de koptekst voor de lengte van de inhoud en er worden geen belangrijke gegevens rechtstreeks aan de URL toegevoegd.
U kunt het netwerkgedeelte van de Google Developer Tools gebruiken om basisinformatie te zien over hoe verzoeken aan de servers worden gedaan.
en u kunt altijd meer waarden toevoegen aan uw Request Headers zoals Cache-Control , Origin , Accept .