After some research, it does appear to be non RFC compliant behavior. I get this behavior when running django via the "python manage.py runserver" command.
The client, in this 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<http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.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. This does appear to be a bug. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
