USE_ETAGS returns status 304 even if response.status_code=400

[mihai.preda@…]

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).

[mihai_preda@…]

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

[Michael Radziej <mir@…>]

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

[mihai_preda@…]

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.

[Michael Radziej <mir@…>]

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

[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.

[Vinay Sajip <vinay_sajip@…>]

Patch for HTTP 304 being returned inappropriately

[Vinay Sajip <vinay_sajip@…>]

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.

[Malcolm Tredinnick]

(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.

[Manuel Saelices <msaelices@…>]

Patch is buggy.

[Manuel Saelices <msaelices@…>]

Patch that fixes previous patch

[Malcolm Tredinnick]

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

[Malcolm Tredinnick]

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