parameters data - Come vengono inviati i parametri in una richiesta POST HTTP?




request example (8)

In una richiesta HTTP GET , i parametri vengono inviati come una stringa di query :

http://example.com/page?parameter=value&also=another

In una richiesta POST HTTP, i parametri non vengono inviati insieme all'URI.

Dove sono i valori? Nell'intestazione della richiesta? Nel corpo della richiesta? Che cosa sembra?


Answers

Prima di tutto, distinguiamo tra GET e POST

Get: è la richiesta HTTP predefinita che viene creata sul server e viene utilizzata per recuperare i dati dal server e la stringa di query che viene dopo ? in un URI viene utilizzato per recuperare una risorsa univoca.

questo è il formato

GET /someweb.asp?data=value HTTP/1.0

qui data=value è il data=value della stringa di query passato.

POST: è usato per inviare dati al server in modo sicuro, quindi tutto ciò che è necessario, questo è il formato di una richiesta POST

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

Perché POST over GET?

In GET il valore inviato ai server viene in genere aggiunto all'URL di base nella stringa di query. Ciò rende i dati in grado di essere compromessi (questo era un problema in passato per Facebook in cui sono state esposte le credenziali). Ecco perché il POST è utilizzato per inviare dati al server che utilizzava l' Request Body per inviare i dati al server che è più sicuro perché nasconde i tuoi dati più ottiene i dati dai campi calcolare la lunghezza di loro e aggiungerli all'intestazione per la content-length e nessun dato importante è direttamente aggiunto URL

ora che la richiesta è resa sicura, qualsiasi valore inviato al server può essere inviato nel Request Body della Request Body poiché il nome implica che conterrà i dati che l'utente desidera inviare (e che viene inviato nel formato URL Encoded ) e le Request Headers della Request Headers mantenere protetta la richiesta confrontando i valori nel Request Body della Request Headers con le Request Headers della Request Headers

Puoi utilizzare la sezione di rete degli Strumenti per sviluppatori di Google per visualizzare le informazioni di base su come vengono fatte le richieste ai server.

e puoi sempre aggiungere più valori nelle Request Headers come Cache-Control , Origin , Accept .


I valori dei form nei POST HTTP vengono inviati nel corpo della richiesta, nello stesso formato della querystring.

Per ulteriori informazioni, vedere le spec .


Risposta breve: nelle richieste POST, i valori vengono inviati nel "corpo" della richiesta. Con i web-form è probabile che vengano inviati con un tipo di media di application/x-www-form-urlencoded o multipart/form-data . I linguaggi di programmazione o i framework che sono stati progettati per gestire le richieste web di solito fanno "The Right Thing ™" con tali richieste e forniscono un facile accesso ai valori prontamente decodificati (come $_REQUEST o $_POST in PHP o cgi.FieldStorage() , flask.request.form in Python).

Ora facciamo una divagazione, che può aiutare a capire la differenza;)

La differenza tra POST richieste GET e POST è in gran parte semantica. Sono anche "usati" in modo diverso, il che spiega la differenza nel modo in cui i valori vengono passati.

GET ( sezione RFC rilevante )

Quando si esegue una richiesta GET , si chiede al server per uno o un insieme di entità. Per consentire al client di filtrare il risultato, può utilizzare la cosiddetta "stringa di query" dell'URL. La stringa di query è la parte dopo ? . Questo fa parte della sintassi URI .

Quindi, dal punto di vista del codice dell'applicazione (la parte che riceve la richiesta), sarà necessario ispezionare la parte della query URI per ottenere l'accesso a questi valori.

Si noti che le chiavi e i valori fanno parte dell'URI. I browser potrebbero imporre un limite alla lunghezza dell'URI. Lo standard HTTP afferma che non ci sono limiti. Ma al momento di questa scrittura, la maggior parte dei browser limita gli URI (non ho valori specifici). GET richieste GET non dovrebbero mai essere utilizzate per inviare nuove informazioni al server. Soprattutto documenti non più grandi. Ecco dove dovresti usare POST o PUT .

POST ( sezione RFC rilevante )

Quando si esegue una richiesta POST , il client sta effettivamente inviando un nuovo documento all'host remoto. Quindi, una stringa di query non ha senso (semanticamente). Questo è il motivo per cui non hai accesso ad essi nel codice dell'applicazione.

POST è un po 'più complesso (e molto più flessibile):

Quando ricevi una richiesta POST, devi sempre aspettarti un "payload", o, in termini HTTP: un corpo del messaggio . Il corpo del messaggio in sé è abbastanza inutile, poiché non esiste un formato standard (per quanto posso dire, forse application / octet-stream?). Il formato del corpo è definito dall'intestazione Content-Type . Quando si utilizza un elemento HTML FORM con method="POST" , di solito è application/x-www-form-urlencoded . Un altro tipo molto comune è multipart/form-data se si utilizzano i caricamenti di file. Ma potrebbe essere qualsiasi cosa , da text/plain , su application/json o persino application/octet-stream personalizzata application/octet-stream .

In ogni caso, se una richiesta POST viene effettuata con un Content-Type che non può essere gestito dall'applicazione, dovrebbe restituire un codice di stato 415 .

La maggior parte dei linguaggi di programmazione (e / o framework web) offre un modo per de / codificare il corpo del messaggio da / verso i tipi più comuni (come application/x-www-form-urlencoded , multipart/form-data o application/json ) . Quindi è facile. I tipi personalizzati richiedono potenzialmente un po 'più di lavoro.

Utilizzando un documento standard in formato HTML codificato come esempio, l'applicazione dovrebbe eseguire i seguenti passaggi:

  1. Leggi il campo Content-Type
  2. Se il valore non è uno dei tipi di supporto supportati, restituire una risposta con un codice di stato 415
  3. altrimenti, decodificare i valori dal corpo del messaggio.

Ancora una volta, lingue come PHP o framework web per altre lingue popolari probabilmente gestiranno questo per voi. L'eccezione a questo è l'errore 415 . Nessun framework può prevedere quali tipi di contenuto la tua applicazione sceglie di supportare e / o non supportare. Questo lo devi decidere tu.

PUT ( relativa sezione RFC )

Una richiesta PUT viene gestita praticamente nello stesso modo di una richiesta POST . La grande differenza è che una richiesta POST dovrebbe consentire al server di decidere come (e se del caso) creare una nuova risorsa. Storicamente (dall'ormai obsoleto RFC2616 è stato creato una nuova risorsa come "subordinato" (figlio) dell'URI a cui è stata inviata la richiesta).

La richiesta PUT al contrario dovrebbe "depositare" una risorsa esattamente a quell'URI e con esattamente quel contenuto. Ne più ne meno. L'idea è che il cliente sia responsabile di creare la risorsa completa prima di "metterla in pratica". Il server dovrebbe accettarlo così com'è sull'URL specificato.

Di conseguenza, una richiesta POST solito non viene utilizzata per sostituire una risorsa esistente. Una richiesta PUT può creare e sostituire.

Nota a margine

Ci sono anche i " parametri del percorso " che possono essere usati per inviare dati aggiuntivi al telecomando, ma sono così rari che non entrerò troppo nei dettagli qui. Ma, per riferimento, ecco un estratto dalla RFC:

A parte i segmenti di punti nei percorsi gerarchici, un segmento di percorso è considerato opaco dalla sintassi generica. Le applicazioni di produzione di URI utilizzano spesso i caratteri riservati consentiti in un segmento per delimitare i sottocomponenti specifici dello schema o del deferente-gestore. Ad esempio, i caratteri riservati alla virgola (";") ed equals ("=") vengono spesso utilizzati per delimitare parametri e valori di parametro applicabili a quel segmento. La virgola (",") carattere riservato viene spesso utilizzata per scopi simili. Ad esempio, un produttore di URI potrebbe utilizzare un segmento come "nome; v = 1.1" per indicare un riferimento alla versione 1.1 di "nome", mentre un altro potrebbe utilizzare un segmento come "nome, 1.1" per indicare lo stesso. I tipi di parametri possono essere definiti dalla semantica specifica dello schema, ma nella maggior parte dei casi la sintassi di un parametro è specifica per l'implementazione dell'algoritmo di dereferenziazione degli URI.


Il contenuto viene inserito dopo le intestazioni HTTP. Il formato di un POST HTTP è di avere le intestazioni HTTP, seguite da una riga vuota, seguita dal corpo della richiesta. Le variabili POST sono memorizzate come coppie chiave-valore nel corpo.

Puoi vederlo nel contenuto non elaborato di un post HTTP, mostrato di seguito:

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

Potete vederlo usando uno strumento come Fiddler , che potete usare per guardare la richiesta HTTP e i payload di risposta inviati sul filo.


Il tipo di supporto predefinito in una richiesta POST è application/x-www-form-urlencoded . Questo è un formato per la codifica di coppie chiave-valore. Le chiavi possono essere duplicate. Ogni coppia chiave-valore è separata da un carattere & , e ogni chiave è separata dal suo valore da un carattere = .

Per esempio:

Name: John Smith
Grade: 19

È codificato come:

Name=John+Smith&Grade=19

Questo viene inserito nel corpo della richiesta dopo le intestazioni HTTP.


I valori vengono inviati nel corpo della richiesta, nel formato specificato dal tipo di contenuto.

Di solito il tipo di contenuto è application/x-www-form-urlencoded , quindi il corpo della richiesta utilizza lo stesso formato della stringa di query:

parameter=value&also=another

Quando si utilizza un caricamento di file nel modulo, si utilizza invece la codifica multipart/form-data , che ha un formato diverso. È più complicato, ma di solito non è necessario preoccuparsi di come appare, quindi non mostrerò un esempio, ma può essere utile sapere che esiste.


Alcuni dei servizi web richiedono di inserire dati e metadati di richiesta separatamente. Ad esempio, una funzione remota può aspettarsi che la stringa di metadati firmata sia inclusa in un URI, mentre i dati sono pubblicati in un corpo HTTP.

La richiesta POST può semanticamente apparire come questa:

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

Questo approccio combina logicamente QueryString e Body-Post utilizzando un singolo Content-Type che è un "parsing-instruction" per un server web.

Nota: HTTP / 1.1 è avvolto con il #32 (spazio) a sinistra e con #10 (avanzamento riga) a destra.


Uso Restler e Needle per scopi di produzione. Sono entrambi molto più potenti di httprequest nativo. È possibile richiedere l'autenticazione di base, l'immissione di intestazione speciale o persino caricare / scaricare file.

Per quanto riguarda le operazioni di post-acquisizione, sono anche molto più semplici da usare rispetto alle chiamate ajax non formattate usando httprequest.

needle.post('https://my.app.com/endpoint', {foo:'bar'}, 
    function(err, resp, body){
        console.log(body);
});






http post parameters request uri