RFC 7231, Section 3.1.1.5 states:
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 aContent-Type
header field is not present, the recipient MAY either assume a media type ofapplication/octet-stream
([RFC2046], Section 4.5.1) or examine the data to determine its type.
The CORS recommendation states:
A header is said to be a simple header if the header field name is an ASCII case-insensitive match for
Accept
,Accept-Language
, orContent-Language
or if it is an ASCII case-insensitive match forContent-Type
and the header field value media type (excluding parameters) is an ASCII case-insensitive match forapplication/x-www-form-urlencoded
,multipart/form-data
, ortext/plain
.
This seems to create a non-specified case for CORS implementations on POST, because using application/octet-stream
forces the non-simple header case, and 'examining the data to determine its type' is not trivial.
What is the most reasonable thing to do in the following cases?
- Content-Length of request is 0. (I'd like to assume
Content-Type: text/plain
to enable the simple header case.) - Content-Length is non-zero. (Default to
application/octet-stream
and force non-simple header case?)
In order to address a comment relating to whether CORS is a security measure or just a model for resource sharing, I'm adding some additional information regarding the implications of these edge cases. Yes, CORS is certainly a model for resource sharing. However, resource sharing worked just fine without CORS, until HTTP clients added security measures to explicitly prevent cross-origin resource retrieval. If implemented improperly, the server-side component of CORS can re-open some of those security holes by improperly sharing resources, especially where credentials are involved. These edge cases are paths that (depending on the answer to the above questions) lead directly to the section on whether to allow cross-origin requests for resources with credentials.
Determining what constitutes a simple header vs. a non-simple header in the above edge cases affects whether some requests are considered simple requests or not, which in turn brings Part 4: Security Considerations into effect:
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.