Re: segfault in dav_validate_request
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':
0. init.. pass
1. begin. FAIL (Could not create new collection
`/uploads/litmus/' for tests: 405 Method Not Allowed
Server must allow `MKCOL /uploads/litmus/' for tests to proceed)
/* Set the ETag header required by dav_meets_conditions() */
->if ((err = (*resource->hooks->set_headers)(r, resource)) != NULL) {
return dav_push_error(r->pool, err->status, 0,
"Unable to set up HTTP headers.",
err);
}
Sorry for this. I did not expect this. But it is all those things I do
not know and understand, why I reverted to code duplicating.
What I introduced in my ugly patch and do not understand well enough is
- call to (*resource->hooks->getetag)(resource)
- reference to resource->exists
Please check, that these can't cause similar trouble.
I tested my ugly code without any DEBUG_xxx-options and run it (local
access only, testing of davfs2) for some month without problems.
Etags:
I do not really understand how mod_dav/apache differentiate Etags send
in the request (if-match etc.) and the Etag, that will be returned.
As far as I can judge:
Etags in conditional requests:
GET, DELETE, PUT, LOCK: most important
COPY, MOVE: useful
MKCOL, UNLOCK, PROPFIND: no need
PROPPATCH: probably no need
Etag-header in response to DAV/HTTP-methods:
GET, HEAD: important to always send Etag
PROPFIND, PROPPATCH: Etag is undefined, should do no harm, but better
not send Etag
DELETE: resource will have vanished afterwards, but Etag could be useful
if DELETE fails.
MKCOL: Etag not defined on collections, but allowed. If mod_autoindex
(?) is used, Etag would make sense.
COPY, MOVE, PUT: An Etag header for the newly created resource would be
very useful, but there are two restrictions:
- as long as mod_dav cannot create strong etags, there is not much use
- for COPY and MOVE on collections it's not defined and not forbidden
LOCK, UNLOCK: probably useless
I don't no about SEARCH and other extensions.
Although I know almost nothing about Apache programming, two remarks on
Segfault:
With Hooks in an complex system like Apache: shouldn't there be a secure
way to avoid calling NULL-Pointer-hooks? What about some kind of Dummy
hook-function: the Dummy will log and return an error, and the hook will
never point to NULL.
DEBUG_GET_HANDLER
There seems to be something wrong. Setting DEBUG should not change the
program in a significant way. You want to debug what's going on in the
real program, not the debug-version.
Cheers
Werner
Re: thoughts on ETags and mod_dav
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 match*. And therefore thought it a waste of time to calculate a string that will never be used. If the intention was, that the weak etag will match on conditional (full body) GET requests, this will change the discussion. But still: Wouldn't in this case Last-Modified-Date be the better, more 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. Is there no way for a cache to uniquely identify variants, but using the cache validator? Isn't this a flaw in the protocol? Cheers Werner
Re: thoughts on ETags and mod_dav
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 dropping that *none*-Etag is the best. Henrik Nordström wrote: Clietn -> Squid -[internet]-> Apache the object in question is having a weak ETag but significant freshness assigned to it via mod_expires or similar. object gets cached by Squid & client with a weak etag client later issues an IF-None-Match request to Squid using the weak ETag. Squid considers the object still fresh and responds with 304. Objections: - Squid seems not to take any information from the Etag. - if the client has the etag and the entity (aka variant), it also has the freshness information from Expires or max-age. It will not contact Squid at all. - is it wise to send an Expires header and an Etag? I don't think so. These are two alternative ways of cache validation. Using both is confusing. Which one has preference? An Etag implies an If-(None)-Match conditional request; what's the use of Expires? - if a client lost the expires header as well as the confusing Etag and sends GET If-Unmodified-Since, how would Squid respond? I guess: 304. So I don't think Squid or the clients will loose anything, when the invalid Etag is dropped. There might be a one in a million chance (I don't know how), that this invalid Etag will save the transfer of an 1 MByte file from Squid to client. But this is not worth the confusion. Cheers Werner
Re: thoughts on ETags and mod_dav
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. Even delaying some PUT-requests (because of locking) would not be a problem, as it would occur rarely. But the problem is, that mod_dav might be bypassed. There are just two possible solutions: 1) make sure, mod_dav can reliable detect any changes by what ever means they are made 2) put the responsibility on the administrator. As I cannot see any realistic solution according 1), I propose solution 2). The suggested check for changes made outside of mod_dav is only meant to catch *most* of the errors made by administrators. It cannot be reliable, and is not meant to take the responsibility from the administrator. A configuration option should allow the administrator to deny his/her responsibility. Doing so, the WebDav-server can no longer create strong Etags it will get inefficient and unreliable. But this would at least be the responsibility of the administrator. The documentation has to be very clear about this. Concerning Etags outside of WebDAV: Henrik Nordström wrote: > ..., 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.. 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, as I do in davfs2. But this is of course not how weak Etags are meant to work and includes some risk. So I still think: Apache's weak Etags are *none*-Etags and simply imply no-cache. It would be better to say this in the clear. BTW: IIS seems to do the same, but this doesn't make it better. Werner
Re: time for 1.3.40 and 2.2.7 ?
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 here, as a startingpoint for reviewing what you propose. Don't try to get me flaming again. But I don't see a lot of competing patches. What I see is a lot of effort from outside apache to provide a patch for a five year old bug, with almost no response from apache developers, at least from no one, who would be able or willing to commit a patch. Although I think, I explained it on http://issues.apache.org/bugzilla/show_bug.cgi?id=38034, here is a summary again. But note: it is up to you, to look at the proposed patched, decide and do the real commit. And please don't try to start another *inconlusive discussion*, if you are not willing to commit a bug fix, that proves to work. The bug --- It's really two bugs: 1. mod_dav does not get the Etag and provide it to ap_meets_conditions. So ap_meets_conditions works with no or the wrong Etag, so decisions involving the Etag can't be correct. 2. ap_meets_conditions does not and cannot know, whether the resource exists. This knowledge is needed for decisions about "If-Match: *" and "If-None-Match: *". That's why these go wrong. How two fix the bugs: - There are two alternatives: fix only for mod_dav (it is very important) or fix in general (would be nice). Fix for mod_dav only: There are two patches (as far as I can see): http://issues.apache.org/bugzilla/attachment.cgi?id=20552 (from me) and http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/[EMAIL PROTECTED] (from Paritosh Shah) These two patches are not competing. They do fundamentaly the same, but the second one (from Paritosh) is the cleaner one. Fix it in general: Even a general solution will still have to fix the bug in mod_dav. There is a patch from Paritosh http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/raw/[EMAIL PROTECTED]/3 To fix the problem with ap_meets_conditions in general, a change in its interface is necessary, to provide ap_meets_conditions with information about the existence of the file. There has been some discussion about how to do this interface change. In my opinion, the best solution is suggested by Paritosh in http://mail-archives.apache.org/mod_mbox/httpd-dev/200711.mbox/[EMAIL PROTECTED] The changes of the code in ap_meets_conditions(2?) should be exactly the ones in http://mail-archives.apache.org/mod_mbox/httpd-dev/200710.mbox/raw/[EMAIL PROTECTED]/2 But editorial changes are necessary, depending on how the interface will be changed exactly. As I understand, Paritosh would be willing, to provide a complete working patch for the general solution. But I also understand, that Tim Olsen would not be fond of wasting time on creating fine patches, that will be ignored anyway. My Proposal: Use the mod_dav-only patch as an intermediate solution, because it is urgent. This solution will not touch anything but mod_dav and can be removed without side effects as soon as a general solution is available. Take the time to consider how to change the interface of ap_meets_conditions (there might be more issues related to this) and include a clean general solution in 2.2.8. Competing Patches - The only competing patch I know of is http://issues.apache.org/bugzilla/attachment.cgi?id=21295 It just does not work, because it ignores half of the bugs and relies on assumptions that are most probably wrong. Werner
Re: thoughts on ETags and mod_dav
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 But I am really frustrated about how this problem is handled by the Apache developers. Happy New Year nonetheless Werner
Re: time for 1.3.40 and 2.2.7 ?
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 news for all developers of WebDAV-clients: A five year old serious bug, that blocks the development of reliable WebDAV-clients (bug #16593 and #38034), is ignored once again, along with the working patches that are provided. Please remove mod_dav and mod_dav_fs from Apache before the release, so providers of WebDAV-services will have to look for a not that badly broken implementation, maybe an implementation that's cared about by it's developers. Werner
