I’m trying out the REST API of the CollectionSpace software, and noticed that sending it a Content-Type header as part of a GET request results in the following error:
HTTP Status 415 - Cannot consume content type
Both of the python REST client libraries I’ve tried, restclient on github and python-rest-client on google code, do send a Content-Type header when making GET requests.
My understanding from reviewing http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html is that clients should only send Content-Type headers on POST and PUT requests. Is that correct?
The fact that both of these libraries do sent the header makes me think that servers typically ignore it, rather than return a client error code.
Although not explicitly outlined in the spec, one could make some inferences. Section 7.2.1 states
That’s pretty obvious, and makes sense. Given that, we can have a look at Section 9 (Method Definitions) to see which ones mention that they’d possibly have an entity in the request body. Three of them mention it:
OPTIONS
POST
PUT
And one method specificially disallows entities, TRACE:
In reality you could send any method (except TRACE) with an entity in the body and a Content-Type header. However, per the spec, I wouldn’t expect the server to do anything with it unless it were one of the three methods above.
I would also say that the software you’re using that responds with the HTTP Status 415 is in violation of the specification.
Section 4.3 says:
Since the spec doesn’t include defined semantics for an entity body with a GET request, the server should ignore it.
Additionally if no entity was provided in the request, and the Content-Length is zero (assuming the Transfer-Encoding header is not set and is not “identity”), the server should not try to consume an entity, regardless of of the request method or whether or not there’s a Content-Type header present. This can be backed up by the order of precedence for determining the message length described in Section 4.4.