Bug 43441 - Incorrect HTTP status for pre-commit-blocked autoversioned PUT request
Summary: Incorrect HTTP status for pre-commit-blocked autoversioned PUT request
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dav (show other bugs)
Version: 2.2-HEAD
Hardware: All All
: P3 normal with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL: http://subversion.tigris.org/issues/s...
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2007-09-20 14:44 UTC by Daniel Rall
Modified: 2018-11-07 21:09 UTC (History)
0 users



Attachments
patch of mod_dav.c (724 bytes, patch)
2009-05-13 02:17 UTC, Csongor Somogyi
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Rall 2007-09-20 14:44:42 UTC
This bug was initially reported against Subversion:

http://subversion.tigris.org/issues/show_bug.cgi?id=2456


Here's the report:

Jack Repenning reports that when using Mac OS X to copy one file to another on a
mounted Subversion-backed DAV share (autoversioning), if the copy is disallowed
by a pre-commit hook, his client goes into an infinite loop.  He says of a
network trace:

    Using "> " to mean "message sent from client to server" and "< " to
    mean the opposite, I see:
   
   > PROPFIND /svn/alm/trunk/www/index%20copy.html
       makes sense: that's the name the copy will have, unless there's
    already such a fine, then there's a cascade
       of fall-back names, so I'm sure OS X checks for that name firsgt
    < HTTP/1.1 404 Not Found
       makes sense: there ain't no such file yet
   > PUT /svn/alm/trunk/www/index%20copy.html
       right, so create it
    < HTTP/1.1 201 Created
       huh?  given the PT integration settings, this area is effectively
    read-only, this shouldn't actually be created!
   > PROPFIND /svn/alm/trunk/www/index%20copy.html
       check if it worked, I guess
    < HTTP/1.1 404 Not Found
       nope, it didn't
   
    At this point, silly OS X seems to go into an infinite loop,
    PROPFINDing away hoping the file will show up some day, and of course
    it never does.

I took a quick glance at mod_dav, and saw that for an autoversioned PUT, any
errors returned from dav_auto_checkin() (from which a Subversion pre-commit hook
error would be returned) are treated only as warnings.  This from dav_method_put():

    /* restore modifiability of resources back to what they were */
    err2 = dav_auto_checkin(r, resource, err != NULL /* undo if error */,
                            0 /*unlock*/, &av_info);

    /* check for errors now */
    if (err != NULL) {
        return dav_handle_err(r, err, NULL);
    }

    if (err2 != NULL) {
        /* just log a warning */
        err2 = dav_push_error(r->pool, err2->status, 0,
                              "The PUT was successful, but there "
                              "was a problem automatically checking in "
                              "the resource or its parent collection.",
                              err2);
        dav_log_err(r, err2, APLOG_WARNING);
    }

This is a bug in Apache's mod_dav, *not* Subversion.  But noting it here because
it is by using Subversion that folks will likely run into it, and members of our
community also overlap the set of mod_dav maintainers.
Comment 1 Csongor Somogyi 2009-05-13 02:17:00 UTC
Created attachment 23649 [details]
patch of mod_dav.c

My proposal here is that we simply replace the code generates warning with a piece of code which generates error.
Comment 2 Csongor Somogyi 2009-05-13 02:21:26 UTC
I have discovered another strange behavior during testing.

When an error occurs during SVN pre-commit and thus autocommit fails the mod_dav simply drops the connection without sending back an error response to the client.

This is true in the case if you don't apply my patch at all. My patch resolves only the situation when a new file is being added. But even when you modify or delete a file the unpatched version will close the connection without sending response to the client.
Comment 3 William A. Rowe Jr. 2018-11-07 21:09:37 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.