On Thu, 11 Oct 2007 17:50:23 -0400 Chris Darroch <[EMAIL PROTECTED]> wrote:
> 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-dev&m=118831732512678&w=2 > > http://issues.apache.org/bugzilla/show_bug.cgi?id=16593 > http://issues.apache.org/bugzilla/show_bug.cgi?id=38034 > http://issues.apache.org/bugzilla/show_bug.cgi?id=42987 > > I'm not about to tackle these all immediately, but I wanted to > send out a couple of proposals and find out what problems folks > might see with them. > > > 1) Per #38034, it appears that ap_meets_conditions() treats "*" > incorrectly. The patch attached to the PR duplicates > ap_meets_conditions() for exclusive use by mod_dav. The only changes > are to add checks on resource->exists in two places and to use > resource->hooks->getetag instead of looking for an ETag header in > r->headers_out. > > In the interest of avoiding code duplication, I wonder if it would > be possible to continue to use ap_meets_conditions() by using > r->no_local_copy in place of resource->exists, and by > setting/unsetting that and an ETag header in r->headers_out in > mod_dav as necessary; e.g., prior to calls to ap_meets_conditions(). > > However, it looks to me as though r->no_local_copy is used in a few > places to bypass the ap_meets_conditions() checks entirely (i.e., to > never send a 304 response in certain cases). > > Does anyone have comments on what the intended purpose > r->no_local_copy is or was, especially in relation to the language > of RFC 2616 sections 14.24 and 14.26 ("if '*' is given and any current > entity exists for that resource ...")? > > Would it be more appropriate and/or required by our backporting > rules to add another field to request_rec, like r->exists, to indicate > to ap_meets_conditions() that a resource does not exist? Or to use > r->notes or conceivably r->finfo for the same purpose? 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 including but not limited to those visible in the filesystem. > Is it even possible to backport a change to the action of > ap_meets_conditions() such that it would start depending on data > which third-party callers won't be supplying? Advice is welcome, > please! > > > 2) I haven't looked at #16593 in any detail, but I wonder if the > change proposed in the patch attached to #38034 where > resource->hooks->getetag is used instead of looking for an ETag header > in r->headers_out might not be an attempt to deal with this issue. > If so, then whatever the eventual solution for #38034 turns out to > be will likely resolve this PR as well. A fix to 38034 that doesn't also fix 16593 would indeed seem perverse, unless perhaps there's some strange subtlety lurking. > 3) Per #42987, it seems as if there's a subtle difference between > the requirements for ETags as described in RFC 2616 section 13.3.3 > and the way we currently generate them in ap_make_etag(). [chop] > But, in the cases handled by ap_make_etag(), the content and/or the > semantic meaning of a resource could always be changing, so weak ETags > would seem to be, as the PR says, simply never appropriate. +1 > So, a modest proposal, which aims to punt the problem to the > administrator, and also to resolve the fact that FileETag is provided > to configure the actions of ap_make_etag(), while mod_dav_fs's > dav_fs_getetag() actions are fixed. The highlights would be: [chop] > Whew. Thoughts and criticisms? Obviously none of this will get > done in the immediate future, but any discussion will, I hope, give me > and others some direction on these issues. Thanks, Feel free to ignore my totally half-baked ideas, but mod_dav is not the only area where we have issues, with ETags. There's also the whole question of negotiated content to consider, and I'm still confused by the problems that still surround PR#39727. If we're reworking ETag logic, we should take the opportunity to deal with this, too. Can we incorporate some kind of tokenisation into ETags that will express dependence on negotiation? For example, Henrik Nordstrom suggests ";gzip". If we expand that to, say, ";CE=gzip", then we can start to apply semantics to decoding the Etag, and determine equivalence. So in that case, we could determine that the (uncompressed) file does indeed match the ETag. Not sure if there's anything we might do with other negotiated headers, but maybe we could leave that open, providing a hook that something like mod_negotiation might someday use. -- Nick Kew Application Development with Apache - the Apache Modules Book http://www.apachetutor.org/
