Roy T. Fielding wrote:
If the weak etags are not being matched to the string etags on
GET, then that is another bug that must be fixed. It is not an
excuse to ignore the HTTP design.
This is a new aspect. I always thought it was intended behaviour, that
weak etags (in Apache) will *never
On sön, 2007-12-30 at 12:54 +0100, Werner Baumann wrote:
Is this true. Is there no way for a cache to uniquely identify variants,
but using the cache validator? Isn't this a flaw in the protocol?
The Content-Location also works as a variant identifier, but requires
that each variant do have a
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.
While on the topic of ETags - I just picked up this regression in 2.2.7-dev
Some innocuous changes to make ETags always 64bit in modules/http/http_etag.c
broke DAV due to it's private dav_fs_getetag routine (ETags never matched
in ap_meets_condition due to the different format).
Patch below
Michael Clark wrote:
Patch below makes mod_dav consistent with the format in http_etag.c
and fixes the cond_put regression with litmus
Index: modules/dav/fs/repos.c
===
--- modules/dav/fs/repos.c(revision 607400)
+++
lör 2007-12-29 klockan 13:19 +0800 skrev Michael Clark:
AFAICT, we are in agreement here. My point was related to the current
inability to detect the direct filesystem access i.e. with the
DavETagIsolation dav+fs you would have to invalidate the ETag unless you
had some sort of mechanism
lör 2007-12-29 klockan 10:42 +0100 skrev Werner Baumann:
I have no idea what this would be. Can you give a *short* outline?
Please note: The weak Etags generated by Apache will *never* match. So
the only way I see, how Apache's weak Etags could be used, is to ignore
the weakness indicator,
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
This is getting ridiculous. ETags are important to caching.
Caching is important to HTTP. If you sum up all of the instances
of webdav in the world (including the ones my company sells), they
still amount to nothing compared to the rest of the uses of HTTP.
If you want strong etags for
Hi --
I'm delighted to see that others have stepped in to keep this
thread going; thank you! Work commitments have kept me from having
the appropriate time to devote to it. It looks like Nick Kew and
Ruediger Pluem have committed some of the patches discussed in the
thread and the bug
lör 2007-12-29 klockan 15:09 -0800 skrev Chris Darroch:
Reading that over, it still makes some sense to me. Apache httpd is
never in the situation implied by the RFC's example, where one wants to
generate a weak ETag because one has knowledge that the file's semantic
meaning hasn't
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.
- if the client has the etag and the entity (aka variant), it also has
the freshness information
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()
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
On Fri, 28 Dec 2007 15:24:07 +0100
Henrik Nordström [EMAIL PROTECTED] wrote:
http://issues.apache.org/bugzilla/show_bug.cgi?id=39727
discussed a number of times here already with varying results..
See this morning's commits. Werner's post reminded me of that one.
fre 2007-12-28 klockan 15:00 + skrev Nick Kew:
That bug shows why there's sometime a problem with such issues.
I committed a fix back in October, but you weren't satisfied with it,
I ahd initial objections because I thought you actually handled weak
ETags, but when remembering that you
Henrik Nordström wrote:
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
lör 2007-12-29 klockan 09:20 +0800 skrev Michael Clark:
You would still suffer from the 1 second racing condition where you
wouldn't known if your stored ETag was up-to-date due to the mtime
resolution (for modifications made outside of WebDAV) forcing you back
into the current weak
Henrik Nordström wrote:
Modifications made using direct filesystem access, in the same second as
the last WebDAV update and only rewriting the file in-place without
changing the length.
That would be a reasonable limitation - hence the suggesion for a
DavETagIsolation dav-only (the default
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.
On 10/20/07, Chris Darroch [EMAIL PROTECTED] wrote:
Paritosh Shah wrote:
Thanks for the patches ... I'll take a look when I get some time.
I used resource-exists as the key instead of
NON_EXTANT_RESOURCE or NO_RESOURCE as suggested by Chris Darroch,
to avoid double negatives.
I
Paritosh Shah wrote:
There are really three states here ( wrt ap_meets_conditions())
1. resource exists
2. resource does not exist
3. nothing is known about existence of the resource
Currently ap_meets_conditions() does not make any assumptions about
existance of the resource ( case 3 ).
I had another look at ap_meets_conditions(), I guess what you say is
true. The current ap_meets_conditions() *does* assume resource exists
( although it does not explicitly state that ). And in that case
NO_RESOURCE would indeed be more appropriate.
- Paritosh.
On 10/25/07, Chris Darroch [EMAIL
There seems to be some consensus that we should add a key to r-notes
as a temporary fix ( at least till 2.4 ). Hence, I'm attaching a patch
- ap_meets_conditions_fixes.patch, with the appropriate fixes to
ap_meets_conditions() using resource-exists key for this purpose.
To be sure that we do not
Paritosh Shah wrote:
Thanks for the patches ... I'll take a look when I get some time.
I used resource-exists as the key instead of
NON_EXTANT_RESOURCE or NO_RESOURCE as suggested by Chris Darroch,
to avoid double negatives.
I wanted to use such a term because the default case, when a
Nick Kew wrote:
My vote goes to r-notes.
Anything else relies on something with semantic significance that'll
risk breaking random things.
For the future (e.g. 2.4), we could review other options. For example,
abstract out r-finfo to a void* with an API for inspecting resources
Chris Darroch wrote:
Hi --
1) Per #38034, it appears that ap_meets_conditions() treats * incorrectly.
More precisely, I should say that ap_meets_conditions() isn't designed
to support the NULL resources of RFC 2518 (WebDAV). I'm certainly no
expert on these issues, so guidance is
On fre, 2007-10-12 at 00:25 -0400, Chris Darroch wrote:
RFC 2616 section 14.24 (and 14.26 is similar) says, If the request
would, without the If-Match header field, result in anything other than a
2xx or 412 status, then the If-Match header MUST be ignored. Thus in
the typical case, if a
Henrik Nordstrom wrote:
On fre, 2007-10-12 at 00:25 -0400, Chris Darroch wrote:
RFC 2616 section 14.24 (and 14.26 is similar) says, If the request
would, without the If-Match header field, result in anything other than a
2xx or 412 status, then the If-Match header MUST be ignored. Thus
Hi --
A couple of months ago a short thread started in relation to the
PRs #16593 and #38034 (which also references #42987) on the various
problems related to ETags:
http://marc.info/?l=apache-httpd-devm=118831732512678w=2
http://issues.apache.org/bugzilla/show_bug.cgi?id=16593
Hi,
There is a way we can avoid code duplication of ap_meets_conditions()
- handle the cases that ap_meets_conditions() does not handle
separately. For this, we can create a new dav_meets_conditions() which
calls ap_meets_conditions() and also handles those other cases. Also,
the problem of ETag
Hi --
1) Per #38034, it appears that ap_meets_conditions() treats * incorrectly.
More precisely, I should say that ap_meets_conditions() isn't designed
to support the NULL resources of RFC 2518 (WebDAV). I'm certainly no
expert on these issues, so guidance is welcome.
RFC 2616 section
32 matches
Mail list logo
