La specifica CORS dovrebbe considerare un'intestazione Content-Type mancante per implicare una "intestazione semplice"?

RFC 7231, Sezione 3.1.1.5 afferma:

A sender that generates a message containing a payload body SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of application/octet-stream ([RFC2046], Section 4.5.1) or examine the data to determine its type.

La raccomandazione CORS afferma:

A header is said to be a simple header if the header field name is an ASCII case-insensitive match for Accept, Accept-Language, or Content-Language or if it is an ASCII case-insensitive match for Content-Type and the header field value media type (excluding parameters) is an ASCII case-insensitive match for application/x-www-form-urlencoded, multipart/form-data, or text/plain.

Questo sembra creare un caso non specificato per implementazioni CORS su POST, perché l'utilizzo di application/octet-stream forza il caso intestazione non-semplice e "l'esame dei dati per determinarne il tipo" non è banale.

Qual è la cosa più ragionevole da fare nei seguenti casi?

• Contenuto: la lunghezza della richiesta è 0. (Mi piacerebbe presumere Content-Type: text/plain per abilitare il caso intestazione semplice .)
• Content-Length è diverso da zero. (Predefinito a application/octet-stream e forza intestazione non semplice caso?)

Per rispondere a un commento relativo al fatto che CORS sia una misura di sicurezza o solo un modello per la condivisione delle risorse, aggiungo alcune informazioni aggiuntive sulle implicazioni di questi casi limite. Sì, CORS è certamente un modello per la condivisione delle risorse. Tuttavia, la condivisione delle risorse ha funzionato perfettamente senza CORS, fino a quando i client HTTP non hanno aggiunto misure di sicurezza per evitare esplicitamente il recupero delle risorse tra origini diverse. Se implementato in modo improprio, il componente lato server di CORS può riaprire alcuni di questi buchi di sicurezza condividendo le risorse in modo improprio, in particolare laddove sono coinvolte le credenziali. Questi casi limite sono percorsi che (in base alla risposta alle domande precedenti) portano direttamente alla sezione relativa alla possibilità di consentire richieste di origine incrociata per le risorse con credenziali.

Determinare cosa costituisce una intestazione semplice rispetto a un'intestazione non semplice nei casi di bordo sopra influisce sul fatto che alcune richieste siano considerate richieste semplici o no, che a sua volta rende effettiva la Parte 4: Considerazioni sulla sicurezza:

A simple cross-origin request has been defined as congruent with those which may be generated by currently deployed user agents that do not conform to this specification. Simple cross-origin requests generated outside this specification (such as cross-origin form submissions using GET or POST or cross-origin GET requests resulting from script elements) typically include user credentials, so resources conforming to this specification must always be prepared to expect simple cross-origin requests with credentials.

Because of this, resources for which simple requests have significance other than retrieval must protect themselves from Cross-Site Request Forgery (CSRF) by requiring the inclusion of an unguessable token in the explicitly provided content of the request.