Django

Code

Ticket #3206 (closed: fixed)

Opened 2 years ago

Last modified 2 years ago

USE_ETAGS returns status 304 even if response.status_code=400

Reported by: mihai.preda@yahoo.com Assigned to: adrian
Milestone: Component: Core framework
Version: SVN Keywords: rev 4235
Cc: Triage Stage: Ready for checkin
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

When USE_ETAGS=True, a page which wants to return a 400 status code (by setting response.status_code=400), may return a 304 status code on reloads (because the content of the page didn't change).

I don't know if this is the correct behavior or not, but I find it surprising that a 400-status is transformed into a 304-status. I would expect USE_ETAGS to only affect pages with 200 status code (or something like it).

Attachments

etag_304.diff (0.6 kB) - added by Vinay Sajip <vinay_sajip@yahoo.co.uk> on 04/18/07 06:52:31.
Patch for HTTP 304 being returned inappropriately
common.py.patch (0.7 kB) - added by Manuel Saelices <msaelices@yaco.es> on 06/01/07 19:13:38.
Patch that fixes previous patch

Change History

12/29/06 12:50:11 changed by mihai_preda@yahoo.com

sorry, I've mispelled the email in the initial ticket.

02/01/07 16:24:15 changed by Michael Radziej <mir@noris.de>

Can you please refer me to any rfc or similar standard that backs your opinion?

02/02/07 02:06:23 changed by mihai_preda@yahoo.com

In RFC 2616, section 10.3.5, 304 Not Modified: "If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code (304)."

I see two conditions for 304: GET, and "access is allowed". I interpret "access is allowed" as meaning: 2xx status code.

Also it is obvious (IMO) that not any status code (e.g. 4xx, 5xx) may be replaced with 304, as this would effectively erase this significant information (the status code).

I would suggest to play it conservativelly and only rewrite 200 to 304, unless some more authoritative understanding of RFC 2616 is expressed.

02/02/07 12:03:53 changed by Michael Radziej <mir@noris.de>

  • stage changed from Unreviewed to Accepted.

Makes sense to me. Thank you, Mihai Preda, for looking this up!

04/17/07 12:06:32 changed by cactus

I also get this behavior.

The client, in my case firefox, upon recieving an etag on a 404 response, will subsequently send an If-None-Match header for the next request of the same 404 page.

The rfc for If-None-Match states: 

If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. (See section 13.3.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26

Django is returning a 304 not modified header, instead of a 404.

In duplicating the headers sent to an apache server serving a 404 page, I get a 404 on subsequent requests, and the if-none-match is responded to with a 404 as expected.

04/18/07 06:52:31 changed by Vinay Sajip <vinay_sajip@yahoo.co.uk>

  • attachment etag_304.diff added.

Patch for HTTP 304 being returned inappropriately

04/18/07 06:55:33 changed by Vinay Sajip <vinay_sajip@yahoo.co.uk>

  • has_patch set to 1.

Patch added to only return a 304 when the original status was 200 and the ETag matches. Possibly any 2xx return should be treated this way, but I've gone with just 200 for now.

05/01/07 03:17:48 changed by Vinay Sajip <vinay_sajip@yahoo.co.uk>

  • stage changed from Accepted to Ready for checkin.

06/01/07 06:47:55 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

(In [5407]) Fixed #3206 -- Changed ETag comparison to only return 304 when the normal status code would be in the range 200 - 299. This matches RFC 2616 requirements. Based on a patch from Vinay Sajip.

06/01/07 19:12:07 changed by Manuel Saelices <msaelices@yaco.es>

  • status changed from closed to reopened.
  • resolution deleted.

Patch is buggy.

06/01/07 19:13:38 changed by Manuel Saelices <msaelices@yaco.es>

  • attachment common.py.patch added.

Patch that fixes previous patch

06/02/07 00:25:34 changed by mtredinnick

Wow.. that's a little humiliating (for me). Thanks for the extra pair of eyes.

06/02/07 02:55:42 changed by mtredinnick

  • status changed from reopened to closed.
  • resolution set to fixed.

(In [5417]) Fixed #3206 -- Fixed typo in [5407]. This time with bonus testing. Thanks, Manuel Saelices.

Add/Change #3206 (USE_ETAGS returns status 304 even if response.status_code=400)




Change Properties
Action