httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Nordström <>
Subject Re: thoughts on ETags and mod_dav
Date Fri, 28 Dec 2007 14:24:07 GMT
fre 2007-12-28 klockan 11:46 +0100 skrev Werner Baumann:
> Paritosh Shah wrote:
>  > Another possible approach would be to create a new
>  > ap_meets_conditions_2() with resource_exists as an explicit argument (
>  > instead of implicitly using r->notes ). Till the next major release we
>  > could just make the current ap_meets_conditions() call
>  > ap_meets_conditions_2() with resource_exists as 1. Later we can make
>  > ap_meets_conditions_2() the default ap_meets_conditions().
> This seems to be the best way to fix this bug.
> I proposed a solution for the Etag-problem, please see

Weak ETags is a bit of a touchy subject in the HTTP specifications. No
one really wants to touch them. The use of weak ETags in conditionals is
limited to If-None-Match. Using a weak ETag in any other conditional
such as If-Match is not allowed for some strange reason. (well, If-Range
is understandable, but If-Match..).

Regarding the problem in issue 42987 the real problem is that Apache can
not make a strong ETag on very new objects. Imho that's the real bug

And yes, it may loook like it's be better to not send a ETag at all than
to send a completely useless one (in terms of Apache), but in the end it
doesn't matter very much, and the weak ETag may be useful to
intermediaries which implements local If-None-Match processing so
sending a weak etag is actually better than none, especially so if the
object Vary:es..

But I do not agree entirely on the conclusions on how mod_dav should
handle ETag. If you store ETag as a property it's better you generate a
real strong ETag without relying on the filesystem meta data, only using
the filesystem meta data as a safety check to guard from direct
filesystem modification not using WebDAV.

> But I am really frustrated about how this problem is handled by the 
> Apache developers.

And I am still waiting for the developers to make up their mind on the
somewhat related mod_deflate ETag issue...

discussed a number of times here already with varying results..

Not frustrated about it, but a little sad that the Apache team do not
take RFC complaince and interoperability more serious.

It almost like there is something with how conditionals is handled in
Apache which is optimized for performance making correctness nearly
impossible it seems..

What is needed to move forward on the discussions on how ETag &
conditionals should be handled with modules and filters?

What I can offer in this discussion is my expertice in HTTP requiremnts,
and general advice on what is required to be able to comply with the
HTTP requirents. But not skilled enough in the Apache module & filter
framework to get my hands dirty in the code I am afraid. But I suppose
if a year more or so passes then I might do that as well.

Squid Developer

View raw message