efficient and less confusing choice of weak validator?
Henrik Nordström wrote:
lör 2007-12-29 klockan 20:56 +0100 skrev Werner Baumann:
Objections:
- Squid seems not to take any information from the Etag.
Yes it does. It uses the ETag as an resource variant identifier.
Is this true
Michael Clark wrote:
I'm getting a segfault here in mod_dav from trunk (after a make clean)
running litmus using extras/httpd-dav.conf whereas it was working for me
last night. Not sure if this a work-in-progress. No time to file a bug
right now as i'm off for the weekend.
- running `locks':
Creating strong Etags would be not to difficult, if the WebDAV
repository is only changed by mod_dav. To me it seems not very
important, how exactly the strong Etag is created:
(filesize+inode+counter, counter only, locking the file for one second,
enforcing an inode-change. All this can work.
First:
I proposed to not only drop that *none*-Etag, but also to send no-cache.
The second is an error. The server should not send no-cache, but let it
to the client and the intermediate caches to decide about caching on the
base of the spec and their configured policy. But I still believe
Jim Jagielski wrote:
Here's what I'd like to propose:
o) We do another triple release: 1.3.40, 2.0.62 and 2.2.7
o) I tag and roll all 3 this Saturday (Dec 29th)
o) We anticipate releasing/announcing all on Jan 2, 2008
It would be a great New Year's gift to the community :)
Great
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()
Nick Kew wrote (concerning bug 38034):
A quick look at the reports shows a lot of competing patches, and a
lot of inconclusive discussion. So it doesn't look like a simple
matter just to apply patches and close bug.
If you're telling us it is a simple matter, perhaps you could post
a summary
