httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Lewis <>
Subject Re: Patches still languishing in Bugzilla
Date Tue, 30 Apr 2013 00:24:29 GMT
On 2013-04-27 10:22:41 -0700, Graham Leggett said:
> On 23 Apr 2013, at 4:27 AM, William Lewis <> wrote:
>> I've tested the patches in 53910, 54610, and 54611 against trunk as 
>> well as 2.4.4; they apply and they fix their respective bugs (at least 
>> as far as my test cases go). I don't have an easy way to test 53525, 
>> though.
> I've committed these to trunk, if you verify for me that the bugs are 
> all fixed I can then propose them for backport to v2.4.

Many thanks! I've verified them, below:

Bug 53910: Oddly enough, the version in trunk doesn't fix the bug. It 
looks like the reason is that the patch applied was different from the 
patch in bugzilla --- the call to ap_unescape_url() was moved to after 
the computation of uri_len, which ended up leaving 
dav_if_header->uri_len inconsistent.

I assume the reason was to do ap_getparents() before unescaping? Doing 
the unescaping after ap_getparents() but before computing uri_len works.

On the other hand, the process of canonicalizing two URI-paths so that 
URI equality can be checked using string compares seems like a really 
common task that should maybe have its own function. (Assuming it's 
possible in the general case! Either that or URIs shouldn't be 
string-compared...) In this code, the canonicalization consists of 
ap_getparents(), unescaping, and removing any trailing slash, but there 
are probably a few other things it should do ... and in DAV code, the 
filesystem provider might want to have a say ...

Bug 54610: Passes my tests in trunk now. Having become a little more 
familiar with mod_dav, though, I'm unsure about one thing: can anyone 
comment on whether DAV_VALIDATE_PARENT should be being passed to 
dav_validate_request() for a COPY as well as a MOVE?

Bug 54611: Fixed in trunk, hooray :)

>> The patch in 50773 no longer applies [....]
> Does this do the trick?

Hmmm, no it doesnt: I'm still getting lock database corruption after a 
lock expires:

[Mon Apr 29 17:19:14.321182 2013] [dav:error] [pid 57745] [client] Could not LOCK /wiml/bugzilla50773/dirA/ due to a 
failed precondition (e.g. other locks).  [500, #0]
[Mon Apr 29 17:19:14.321193 2013] [dav:error] [pid 57745] [client] The locks could not be queried for verification 
against a possible "If:" header.  [500, #0]
[Mon Apr 29 17:19:14.321199 2013] [dav:error] [pid 57745] [client] The lock database was found to be corrupt. An indirect 
lock's direct lock could not be found.  [500, #402]


View raw message