È necessaria un'intestazione del tipo di contenuto per le richieste HTTP GET?

154

Per quanto ho capito ci sono due posti in cui impostare il tipo di contenuto:

  1. Il client imposta un tipo di contenuto per il corpo che sta inviando al server (ad es. Per posta)
  2. Il server imposta un tipo di contenuto per la risposta.

Questo significa che non devo o non devo impostare un tipo di contenuto per tutte le mie richieste get (lato client). E se posso o dovrei quale tipo di contenuto sarebbe?

Inoltre ho letto in alcuni post che il tipo di contenuto del client specifica quale tipo di contenuto il cliente vorrebbe ricevere. Quindi forse il mio punto 1 non è giusto?

http  get  content-type 
— Martin Flucka
fonte

Risposte:

112

Secondo la RFC 7231 sezione 3.1.5.5 :

Un mittente che genera un messaggio contenente un corpo di payload DOVREBBE generare un campo di intestazione Content-Type in quel messaggio a meno che il tipo di supporto previsto della rappresentazione allegata non sia sconosciuto al mittente. Se non è presente un campo di intestazione Content-Type, il destinatario PUO 'assumere un tipo di media di "application / octet-stream" ( [RFC2046], Sezione 4.5.1 ) o esaminare i dati per determinarne il tipo.

Significa che l' Content-Typeintestazione HTTP deve essere impostata solo per PUTe POSTrichieste.

— Epoc
fonte
5
@Epoc, il messaggio citato è nella migliore delle ipotesi implicito. In realtà non dice che i messaggi senza body-entità SHOULD NOTincludano un Content-Type. Abbiamo un preventivo esplicito?
— Pacerier
1
@Pacerier, per favore, non dare la conclusione fondamentale della risposta di qualcun altro, anche se è falso. Concordo sul fatto che la risposta di Epoc sia errata: nulla nella sezione che ha citato conferma la conclusione della sua risposta e merita di essere annullato. Ma ciò non significa che dovresti modificare la risposta per eliminare la sua premessa principale e quindi cambiare totalmente il suo significato.
— Mark Amery
8
Penso che state leggendo le parole di @Epoc troppo alla lettera. Certo, la sezione citata non significa ciò che dice che significa. Ma penso che la conclusione sia corretta nel contesto della domanda dei PO. L'OP sta cercando chiarezza su quando ha senso includere Content-Type e quando non lo fa. Epoc ha fornito informazioni su come viene utilizzata l'intestazione e ha tratto la conclusione che qualsiasi sviluppatore ragionevole dovrebbe: "dovresti" utilizzare un tipo di contenuto per richieste con corpi payload (principalmente PUT e POST) e probabilmente "non dovresti" utilizzare in luoghi in cui non è utile, come GET o HEAD, ecc.
— JVMATL
1
La tua dichiarazione post, "Significa ...". - è un tratto.
— Adrian Bartolomeo
64

Le richieste get non devono avere un tipo di contenuto perché non hanno un'entità richiesta (ovvero un corpo)

— Dmitry Negoda
fonte
31
@Dmitry, citazione necessaria , altrimenti si presenta come un presupposto, non come un dato di fatto.
— Pacerier,
6
Mentre sono d'accordo che la specifica non dice che non puoi avere Content-Type su un GET, .Net sembra applicarlo nel suo HttpClient. Vedi stackoverflow.com/questions/10679214/…
— Adam
27

La risposta accettata è sbagliata. La citazione è corretta, l'affermazione che PUT e POST devono averla non è corretta. Non è richiesto che PUT o POST abbiano effettivamente contenuti aggiuntivi. Né esiste un divieto che GET abbia effettivamente dei contenuti.

Le RFC dicono esattamente cosa significano. IFF il tuo lato (client o server di origine) invierà contenuto aggiuntivo, oltre alle intestazioni HTTP, DOVREBBE specificare un'intestazione Content-Type. Tuttavia, è possibile omettere il tipo di contenuto e includere comunque il contenuto (ad esempio, utilizzando un'intestazione Content-Length).

— user4157069
fonte
0

Risposta breve: molto probabilmente, non è necessaria un'intestazione del tipo di contenuto per le richieste HTTP GET. Ma le specifiche non sembrano escludere nemmeno un'intestazione del tipo di contenuto per HTTP GET.

Materiali di supporto:

  1. "Content-Type" fa parte dei metadati della rappresentazione (ad es. Payload). Citato da RFC 7231 sezione 3.1 :

    3.1. Metadati di rappresentazione

    I campi dell'intestazione della rappresentazione forniscono metadati sulla rappresentazione. Quando un messaggio include un corpo di payload, i campi dell'intestazione della rappresentazione descrivono come interpretare i dati di rappresentazione racchiusi nel corpo del payload. ...

    I seguenti campi di intestazione trasmettono metadati di rappresentazione:

    +-------------------+-----------------+
| Header Field Name | Defined in...   |
+-------------------+-----------------+
| Content-Type      | Section 3.1.1.5 |
| ...               | ...             |

    Citato dalla sezione 3.1.1.5 di RFC 7231 (a proposito, la risposta attualmente selezionata aveva un refuso nel numero di sezione):

    Il campo di intestazione "Tipo di contenuto" indica il tipo di supporto della rappresentazione associata

  2. In tal senso, Content-Typeun'intestazione non riguarda in realtà una richiesta HTTP GET (o una richiesta POST o PUT, per quella materia). Riguarda il payload all'interno di tale richiesta qualunque . Quindi, se non ci sarà carico utile, non è necessario Content-Type. In pratica, alcune implementazioni sono andate avanti e hanno reso comprensibile tale presupposto. Citato dal commento di Adam :

    "Mentre ... le specifiche non dicono che non puoi avere Content-Type su un GET, .Net sembra applicarlo nel suo HttpClient. Vedi questo SO domande e risposte ."

  3. Tuttavia, a rigor di termini, le specifiche stesse non escludono la possibilità che HTTP GET contenga un payload. Citato da RFC 7231 sezione 4.3.1 :

    4.3.1 OTTIENI

    ...

    Un payload all'interno di un messaggio di richiesta GET non ha una semantica definita; l'invio di un corpo di payload su una richiesta GET potrebbe causare il rifiuto di alcune implementazioni esistenti.

    Quindi, se il tuo HTTP GET include un payload per qualsiasi motivo, anche Content-Typeun'intestazione è probabilmente ragionevole.

— RayLuo
fonte
-2

Il problema di non trasferire il tipo di contenuto su un messaggio GET è che il tipo di contenuto è irrilevante perché il lato server determina comunque il contenuto. Il problema che ho riscontrato è che ora ci sono molti posti in cui i loro servizi web sono stati configurati per essere abbastanza intelligenti da raccogliere il tipo di contenuto che si passa e restituire la risposta nel "tipo" richiesto. Per esempio. stiamo attualmente inviando messaggi a un posto che per impostazione predefinita è JSON, tuttavia hanno impostato il loro servizio Web in modo tale che se si passa un tipo di contenuto di xml restituiranno xml anziché il loro valore predefinito JSON. Che penso che andare avanti sia una grande idea

— Leeroy
fonte
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.