Rack::Lint should not require Content-type header if no body is present #472

Closed
aaronpk opened this Issue Dec 24, 2012 · 8 comments

6 participants

@aaronpk

According to the HTTP spec, a Content-type header is recommended, but not actually required for requests. http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body.

It's understandable for Lint to expect a Content-type header when there is an entity body. However, if there is no entity body (HTTP 204, 301, 302, 304, 405, etc) then Lint should not require the Content-type header.

It appears that Lint has used the list of HTTP codes explicitly disallowing an entity body as the list of acceptable codes to not require a Content-type header. I believe this is incorrect behavior, and should be modified to only require a Content-type header if there is data in the request body.

@oscardelben

Note that Rack::Lint is meant to validate your app against the Rack spec, not the the HTTP spec. In particular, the Rack spec states the following:

There must be a Content-Type, except when the Status is 1xx, 204, 205 or 304, in which case there must be none given.
@aaronpk

Ok, I see. In that case, I would argue that the Rack spec should match the HTTP spec more closely. Otherwise, you're going to keep seeing changes to the spec like this: 2c5b076#SPEC

@oscardelben

I'm not worried about the list of status codes changing frequently. On the other hand, changing the SPEC at this point is kind of a big deal, as clients may rely on its current behavior, and you'd have to ask the maintainers to target the next major release. If this is behavior causing you trouble though, I'd like to know.

@raggi
Official Rack repositories member

Rack SPEC is loosely based on cgi.rb and HTTP, with some balances in between. I've just relaxed the Content-Type stuff though, as it was arguably too strict and caused problems with some mime selection complexities and heuristics with modern media types. As such, this was closed by 3623d04 and 2138f0b.

@raggi raggi closed this Dec 30, 2012
@gustavosaume

Even though I definitely prefer the new, more relaxed wording on the spec regarding the Content-Type that now states:

=== The Content-Type
There must not be a <tt>Content-Type</tt>, when the +Status+ is 1xx,
204, 205 or 304.

The Content-Type header should not be required for the other status responses when there is no content. We had to add a Content-Type for a 405 response even though we are not sending any content, just to avoid a LintError.

@rkh
Official Rack repositories member

But you are sending content, it's just empty. Not sure.

@dblock

What should the content type be for an empty response on a 405? also on SO

@dblock

@raggi Can you comment on this, please? I say Rack::Lint is not doing the right thing raising an error when there's no Content-Type with a 405, but if you feel strongly otherwise we'll consider adding a Content-Type text/plain into Grape.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment