neomerx / json-api

Framework agnostic JSON API (jsonapi.org) implementation

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Responses with 204 HTTP status code (aka "no content") actually have "Content-Type" header set.

neomerx opened this issue · comments

This is actually somewhere in between bug and not but closer to annoying 'feature' IMHO

RFC 7231 says

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.

In other words, it recommends adding the header if Response has a body. If you think it's a server's obligation read the following

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.

The RFC says nothing if the header may be omitted for bodyless responses. However, as it allows omit it reardless it would be reasonable to keep it only for requests with a body.

I 'fixed' this behavior though it appeared that someone on my machine from stack PHP_dev_server -> Browser sets it to 'text/html'.
I'm committing the changes as it makes it cleaner, improves tests a bit and reduces a few CPU cycles for 204 responses. It's a responsibility of a developer/software stack add/not to add the header for such responses.

I encountered a problem somehow related to this issue:

If a request contains for example a bad filter parameter (or just "GET [...]?filter=") an JsonApiException is thrown (see QueryParametersParser#L177 ). That exception contains only the status code 400 without further information.

Using flute the response will have this body: { "errors": [] }. This does not seem right.

If I instead catch that exception and generate a code response, the status code 400 and "Content-Type: application/vnd.api+json" will be set, but as the body is empty, this isn't valid either.

Any ideas on how to proceed?

@lunika You are right. The parser should provide some details on errors. I created a separate issue #185

UPD: fixed in develop branch.

@lindyhopchris I'm about to release this change. I would appreciate your feedback on this to be sure it won't break anything in your project (you might need to check your 204 responses with no content).

@neomerx will take a look now

@neomerx this all looks fine - tests are all passing in my library and one of the production apps using it. thanks for giving me the chance to look at it.

@lindyhopchris Thanks. I'm going to release the new version today or tomorrow.

released in 1.0.5