This project is archived and is in readonly mode.
[PATCH] Don't set Content-Length on 304 responses
Reported by Jonathan del Strother | September 2nd, 2008 @ 05:42 PM | in 2.x
Heya
8aad8cb3906fce40fa583839fec7f8591fab8ec7 changed things so that 304 responses no longer have a content length of 0. This is probably a good thing : I suspect that 304s should not have a Content-Length header (though I'm struggling to find a definitive answer in the HTTP spec)
Unfortunately, as of that commit, the content length of 304s is set to the content length of the original response.
This causes huge problems when using conditional GETs with Cocoa's NSURLConnection, where it will hang around waiting for the rest of the content length, which will never arrive, and the connection will time out.
The attached patch shuffles the order of the response setup, so that content length is only set after the conditional GETs are handled.
Comments and changes to this ticket
-
Repository September 2nd, 2008 @ 10:39 PM
- State changed from “new” to “resolved”
(from [6cfb70023a7b102debaa7f1505b173556a285ae7]) Don't set Content-Length on 304 responses
Commit 8aad8c claimed to do this, but it checks for the 304 status too early, before handle_conditional_get! has overridden it.
[#958 state:resolved]
Signed-off-by: Jonathan del Strother jon.delStrother@bestbefore.tv Signed-off-by: Jeremy Kemper jeremy@bitsweat.net http://github.com/rails/rails/co...
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
People watching this ticket
Jeremy Kemper
Jonathan del Strother
Attachments
Referenced by
-
958
[PATCH] Don't set Content-Length on 304 responses
[#958 state:resolved]