DO NOT REPLY [Bug 43441] New: - Incorrect HTTP status for pre-commit-blocked autoversioned PUT request

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=43441>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43441

           Summary: Incorrect HTTP status for pre-commit-blocked
                    autoversioned PUT request
           Product: Apache httpd-2
           Version: 2.2-HEAD
          Platform: All
               URL: http://subversion.tigris.org/issues/show_bug.cgi?id=2456
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: mod_dav
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: dlr@apache.org


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.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org