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 reports; again, thanks to all involved. It would be great if the problems addressed in #38034 and #16593 could be handled properly (at least with respect to mod_dav).
Roy T. Fielding wrote:
If you want a better meets_conditions in general, then write a new one with a new interface that can pass in the metadata for the chosen representation (if any) and does not stink of stupid DAVisms (like "resource exists" where it should say "representation exists"). Do not make patches to the old interface because those won't be distributed until Apache 3.x.
It looks like the patch Nick committed for mod_dav essentially wraps ap_meets_conditions() and deals with the additional If-Match/If-None-Match tests outside of that function. That should suffice to handle all the DAV issues from #38034 and that may be entirely sufficient until 3.x. With an eye on handling those additional If-Match/If-None-Match tests for all users, not just mod_dav, I'd hoped to allow callers to pass the necessary extra info to ap_meets_conditions() in r->notes. The function would remain entirely backwards-compatible for existing users, of course. I think Paul Querna suggested creating a parallel ap_meets_conditions2(), as reported by Paritosh Shah, and that may be less crufty than my notion. I just wish I had an idea for more meaningful name for such a replacement function.
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, if I understand correctly, is the subject of #42987. My own best effort at understanding the issue, from my original post, is below -- if you can weigh in with any clarifications or corrections, that would be very helpful (to me, at least!) Chris Darroch wrote:
The RFC says that a file's mtime "could" be a weak validator, because the file might change more than once in a second. But I think the subtly important issue here is that word "could". If I understand it correctly, the implication is that one has [a] resource for which one wants to generate weak ETags only, because one knows the semantic meaning isn't changing although the content may be. In this particular case, the modification time *might* be appropriate to use as a weak validator (although that seems somewhat unlikely, because non-semantic changes that occurred seconds apart would still cause different weak ETags to be generated, which probably isn't what you'd want in this circumstance). 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.
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 changed, and therefore one can use the file's mtime to generate the weak ETag. Since httpd is never in that situation, the RFC's example essentially doesn't apply to the problem httpd faces when a file's modification time is the current time (to the second). Put another way, modification times are not appropriate as weak ETag sources when one doesn't know, somehow, that a file's semantic meaning hasn't changed. I think! :-/ Currently, when httpd notices that a file's mtime and the current time are the same, ap_make_etag() just creates its usual ETag but then marks it as weak. This has the advantage of being fast, since, as you point out, high performance is critical. If I understand the issues at hand correctly, though, to resolve #42987 we should really just not generate any ETag at all in this case. I'd proposed putting this into the hands of the administrator via a configuration directive:
- add a nomtime=none|weak|ignore option to FileETag (in the manner of ProxyPass) which specifies what to do when the MTime option is configured but the file's mtime is the same as r->request_time; the default value is "weak" to retain backward compatibility
So, the out-of-box default would be the current functionality. One could tune it to not generate any ETag in this particular situation (where mtime is used a part of the strong ETags, and the mtime and current time match), or to ignore this situation and just always send out a strong ETag. Does that seem out to lunch? Certainly the intention is not to run counter to the RFC, but rather to do the best job of conforming to it while providing high performance, and being backwards- compatible with existing behaviour where that's appropriate. Chris. -- GPG Key ID: 366A375B GPG Key Fingerprint: 485E 5041 17E1 E2BB C263 E4DE C8E3 FA36 366A 375B
