Lint raises if 200 response with no body doesn't contain "Content-Type"
Reported by Iñaki Baz Castillo | December 24th, 2009 @ 01:00 PM
When performing a PUT request my app replies 200 or 201 with "Content-Length: 0" and without body and "Content-Type".
However Lint raises bacause a 200 or 201 response "must contain 'Content-Type'":
STATUS_WITH_NO_ENTITY_BODY = Set.new((100..199).to_a << 204 << 304)
...
assert("No Content-Type header found") {
Rack::Utils::STATUS_WITH_NO_ENTITY_BODY.include? status.to_i
}
RFC 2616 states that a message requires "Content-Type" in case it has body:
RFC 2616 - 7.2.1 Type
Any HTTP/1.1 message containing an entity-body SHOULD include a
Content-Type header field defining the media type of that body.
Comments and changes to this ticket
-
Matías Flores January 21st, 2010 @ 09:13 PM
It's a bit confusing, as that same RFC but on a different section (4.3) also states that:
- All responses to the HEAD request method MUST NOT include a message-body.
- All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body.
- All other responses do include a message-body, although it MAY be of zero length.
So, strictly speaking, it seems that in the example you mentioned you do have a message-body but of zero length. And as per section 7.2.1 if you have a body then you SHOULD include the Content-Type header.
Notice that even if this interpretation happens to be right this would still be a SHOULD, not a MUST, so your point may still be valid. I'm not sure how Rack::Lint is or should be handling unsatisfied SHOULDs.
-
Graham Batty March 2nd, 2010 @ 10:36 PM
The RFC doesn't seem confusing to me at all. 200 replies always have a content body, and content-length:0 implicitly admits this anyways. If there's a body, it has a type and the type should be sent back.
It seems like SHOULDs should really probably be warnings, not errors. I don't think Lint is capable of that as it stands, though.
-
raggi May 3rd, 2011 @ 07:44 AM
- State changed from “new” to “hold”
- Milestone order changed from “0” to “0”
nginx disagrees, and ELB agrees. Not concerned. Holding until someone produces a patch
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
Matías Flores
raggi