etag and 404.

When I enable etags, django is sending back an etag on 404
pages.
When a client does a subsequent request for  the same
nonexistent
page, a 304 response is sent back, because the page has not
changed
(based on the etag).

When I disable etags, multiple requests for a non existent
page all
return 404 as expected.

Is there a way to disable etag generation on 404 pages,
while still
performing it on all 'real' pages?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> When I enable etags, django is sending back an etag on
404 pages.
> When a client does a subsequent request for  the same
nonexistent
> page, a 304 response is sent back, because the page has
not changed
> (based on the etag).
>
> When I disable etags, multiple requests for a non
existent page all
> return 404 as expected.
>
> Is there a way to disable etag generation on 404 pages,
while still
> performing it on all 'real' pages?

I guess the simplest thing would be to write a middleware
class, that
inherits the conditional get middleware, overloads the
method and
simply add a condition, that checks the status code of the
response.
If it's 404, remove the Etag. Then use that middleware
instead of the
normal one.

I think the behaviour is correct though, why do you want to
redefine it ?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

> I think the behaviour is correct though, why do you
want to redefine it ?

If the behavior is indeed correct, then I don't think I need
to
redefine it.
It just seemed odd to return a 'not-modified' response to a
query for
a page that did not exist.

Apache, when configured with mod_expires, does *not* return
etags on
404 responses, but of course does on 200 responses.

Based upon that, to me it seemed like incorrect behavior.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 16/04/07, cactus <cactuswaxgmail.com> wrote:
>
> > I think the behaviour is correct though, why do
you want to redefine it ?
>
> If the behavior is indeed correct, then I don't think I
need to
> redefine it.
> It just seemed odd to return a 'not-modified' response
to a query for
> a page that did not exist.
>
> Apache, when configured with mod_expires, does *not*
return etags on
> 404 responses, but of course does on 200 responses.
>
> Based upon that, to me it seemed like incorrect
behavior.

Correct, but a browser, or a proxy server in the request
chain would
get the not-modified, only if it already got the correct
response
once, so essentially what is being said is "the page
you're requesting
is still not there", with the 404 page you've already
sent. It's not
stopping you to redefine the behaviour though - you're
always free to
do that, if you find it odd or inconsistent.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

I stand corrected, thank you for the referenced reply. I've
missed
that part of the specification. If you make any changes to
the
conditional get middleware, please consider sending a patch
for it,
that could be incorporated in the code later, hopefully.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "Django users" group.
To post to this group, send email to django-usersgooglegroups.com
To unsubscribe from this group, send email to
django-users-unsubscribegooglegroups.com
For more options, visit this group at htt
p://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---