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 > http://issues.apache.org/bugzilla/show_bug.cgi?id=42987
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 there. 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... http://issues.apache.org/bugzilla/show_bug.cgi?id=39727 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. Regards Henrik Squid Developer
