Qual è la differenza tra "Richiedi payload" e "Dati modulo" come si vede nella scheda Rete degli strumenti di sviluppo di Chrome


244

Ho una vecchia applicazione web che devo supportare (che non ho scritto).

Quando compilo un modulo e invio quindi controllo la scheda "Rete" in Chrome vedo "Richiedi payload" dove normalmente vedrei "Dati modulo". Qual è la differenza tra i due e quando verrebbe inviato uno anziché l'altro?

Ho cercato su Google questo, ma non ho trovato alcuna informazione che lo spieghi (solo le persone che cercano di ottenere app javascript per inviare "Dati modulo" invece di "Richiedi payload".




2
Ancora non capisco qual è la differenza tra i due. "Richiedi payload" è solo una richiesta che non è stata codificata con un tipo?
red888,

Risposte:


274

Il payload della richiesta - o per essere più precisi: corpo del payload di una richiesta HTTP - sono i dati normalmente inviati da una richiesta POST o PUT . È la parte dopo le intestazioni e il CRLFdi una richiesta HTTP .

Una richiesta con Content-Type: application/jsonpotrebbe apparire così:

POST /some-path HTTP/1.1
Content-Type: application/json

{ "foo" : "bar", "name" : "John" }

Se lo invii per AJAX, il browser ti mostra semplicemente cosa sta inviando come corpo del payload. Questo è tutto ciò che può fare perché non ha idea da dove provengano i dati.

Se si invia un HTML-Form con method="POST"e Content-Type: application/x-www-form-urlencodedo Content-Type: multipart/form-datala vostra richiesta potrebbe essere simile a questa:

POST /some-path HTTP/1.1
Content-Type: application/x-www-form-urlencoded

foo=bar&name=John

In questo caso i dati del modulo sono il payload della richiesta. Qui il Browser ne sa di più: sa che la barra è il valore del campo di input foo del modulo inviato. Ed è quello che ti sta mostrando.

Pertanto, differiscono nel modo, Content-Typema non nel modo in cui i dati vengono inviati. In entrambi i casi i dati si trovano nel corpo del messaggio. E Chrome distingue come i dati ti vengono presentati negli Strumenti per gli sviluppatori.


3
C'è un motivo per preferire l'uno all'altro in termini di dimensioni, ecc. Soprattutto per le chiamate AJAX leggere?
utente

@buffer mi dispiace, non capisco la tua domanda.
lefloh,

3
Se sto inviando una chiamata AJAX, posso impostare il tipo di contenuto su jsono x-www-form-urlencoded. Il primo invia i dati come payload di richiesta mentre il secondo li codifica come query url. Entrambi sembrano funzionare bene. C'è un motivo per preferirne uno? Vedo la maggior parte dei siti Web come Twitter, Google, Facebook, Stackoverflow impostare il tipo di contenuto come x-www-form-urlencoded. Qualche motivo specifico?
utente

2
Questo non è realmente correlato all'OP, ma forse questa risposta aiuta .
lefloh

13

In Chrome, la richiesta con "Content-Type: application / json" viene visualizzata come Richiesta PayedLoad e invia i dati come oggetto json.

Ma la richiesta con 'Content-Type: application / x-www-form-urlencoded' mostra i dati del modulo e invia i dati come chiave: coppia di valori , quindi se si dispone di un array di oggetti in una chiave , il valore di quella chiave risulta piatto :

{ Id: 1, 
name:'john', 
phones:[{title:'home',number:111111,...},
        {title:'office',number:22222,...}]
}

invia

{ Id: 1, 
name:'john', 
phones:[object object]
phones:[object object]
}

PHP è ovviamente malvagio. La popolarità di application / x-www-form-urlencoded è definita dalla popolarità di PHP.
Brian Haak,

4
declassato perché non esiste un "oggetto json". i dati json inviati vengono inviati come una semplice stringa perché json è essenzialmente una stringa. puoi ovviamente convertirlo in un "oggetto" standard con json_encode ma neanche questo lo rende un "oggetto json".
Volkan Ulukut,

Ok, penso che l'oggetto template javascript json o solo l'oggetto javascript sia migliore
Mohammadreza,

1
Solo "json" o se si desidera enfatizzare il tipo "json string" andrebbe bene.
Volkan Ulukut,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.