Fix invalid response for empty reply() (v8.x regression)

[kanongil]

The content-type header for empty responses used to not be set when calling reply(null), reply(''), etc in the route handler.

In 8.0 the header is set as application/json. This is a problem, as an empty string is not valid JSON, causing eg. $.ajax() to cast a TypeError when in JSON mode.

This patch changes the content-type to plain text/html for empty responses, which is valid.

[gergoerdosi]

I'm not sure about this change. If client sets Accept: application/json then returning text/html may be unexpected.

I think this is more of a client error. An empty response should use the status code 204. And in that case client should not try to parse the response. This has been actually reported:

http://bugs.jquery.com/ticket/13292
jquery/jquery#1142

[kanongil]

I'm pretty sure it's a bad idea to change the response to a 204 code in a generic way, and anyway is not within the scope of a bug fix.

Regarding Accepts, this should already be handled at the application level by explicitly specifying the mime type, and if you return an empty JSON response without a 204 code, it is an application bug.

[kanongil]

If this is likely to cause issues, I'm open to changing it to only set text/html when you reply('') which is clearly intended as text. Another possible fix is to revert to the old behavior and not set the content-type header at all.

[gergoerdosi]

I'm pretty sure it's a bad idea to change the response to a 204 code in a generic way, and anyway is not within the scope of a bug fix.

I didn't suggest to change the status code in hapi. I meant developers should use reply().code(204) instead of reply(null, null) in the handler.

Actually, I'm not sure your proposed change can be considered a bug fix. It can be considered a breaking change too as it changes the response. If clients are configured to take action based on the type of the response, then this change will break their behavior. Application code needs to be changed too (reply().code(204) to reply().code(204).type('application/json')).

Regarding Accepts, this should already be handled at the application level by explicitly specifying the mime type, and if you return an empty JSON response without a 204 code, it is an application bug.

You are right. It is an application bug and your proposed change makes sense now.

[kanongil]

The bug fix can indeed be considered a breaking change depending on which angle you look at it from.

Since the changed behavior is not mentioned in #2186, and we are very early in the current release, I want to label it as a bug fix for an unannounced regression. In any case, the docs doesn't mention what content-type can be expected from an empty reply(). Also note my earlier suggestions towards a less invasive fix.

[gergoerdosi]

Your proposed change makes sense, an empty 200 response with the application/json header is just wrong.

Maybe the old behavior was correct in some way, because a reply().code(204) should not set the content-type header. In case of a 204 response text/html is just as good/wrong as application/json. In any case, now that hapi 8.0.0 is out, both behavior (old and your proposed) would be a breaking change. However I would like to get this fixed too.

[leftieFriele]

We encountered the same issue. Issuing a request with Wreck and replying reply().code(204) and we get 'Unexpected end of line' when Wreck tries to parse the response.
The proposed change solves the problem and the solution makes sense.

[kanongil]

@leftieFriele That sounds like a bug in Wreck. It should not try to parse a response with code 204.

Edit: Related wreck pull request: hapijs/wreck#69.

[arb]

I think reply('') should set the header to "text/html". Any other falsy values (null or undefined) should leave the header unset IMO.

[lock]

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.