Bug 35981

Summary: mod_dav overrides dav_fs response on PUT failure
Product: Apache httpd-2 Reporter: Mark Rinfret <mrinfret>
Component: mod_davAssignee: Apache HTTPD Bugs Mailing List <bugs>
Severity: major CC: alejandro.alvarez.ayllon, basant.kukreja
Priority: P2 Keywords: MassUpdate, PatchAvailable
Version: 2.0.54   
Target Milestone: ---   
Hardware: All   
OS: All   

Description Mark Rinfret 2005-08-02 21:06:02 UTC
mod_dav discards the error status returned from dav_open_stream() during a 
failed PUT request. We have modified repos.c to reject certain filename 
extensions. Upon receipt of an invalid extension, our dav_fs_open_stream 
returns thus:
    return dav_new_error(resource->pool, HTTP_UNSUPPORTED_MEDIA_TYPE, 0,

However, dav_method_put (mod_dav.c) overrides this response. (The author even 
indicates that this probably isn't the right thing to do.)
    if ((err = (*resource->hooks->open_stream)(resource, mode,
                                               &stream)) != NULL) {
        /* ### assuming FORBIDDEN is probably not quite right... */
        err = dav_push_error(r->pool, HTTP_FORBIDDEN, 0,
                                          "Unable to PUT new contents for %s.",
                                          ap_escape_html(r->pool, r->uri)),
Thus, we are getting FORBIDDEN at the client when we want 
Comment 1 Basant Kumar Kukreja 2007-03-07 09:48:15 UTC
RFC 2518
doesn't state that PUT must return HTTP_UNSUPPORTED_MEDIA_TYPE (415).
(HTTP/1.1 rfc 2068 states that PUT can return HTTP_UNSUPPORTED_MEDIA_TYPE but it
is not mandatory for dav rfc)

415 is returned by MKCOL though.

I agree that dav_method_put ignores that status code of error returned by
Comment 2 Basant Kumar Kukreja 2007-03-07 09:59:58 UTC
Suggested fix :

Index: modules/dav/main/mod_dav.c
--- modules/dav/main/mod_dav.c	(revision 512953)
+++ modules/dav/main/mod_dav.c	(working copy)
@@ -959,7 +959,8 @@
     if ((err = (*resource->hooks->open_stream)(resource, mode,
                                                &stream)) != NULL) {
         /* ### assuming FORBIDDEN is probably not quite right... */
-        err = dav_push_error(r->pool, HTTP_FORBIDDEN, 0,
+        int status = err->status ? err->status : HTTP_FORBIDDEN;
+        err = dav_push_error(r->pool, status, 0,
                                           "Unable to PUT new contents for %s.",
                                           ap_escape_html(r->pool, r->uri)),

I am not confident of this fix because it may cause unexpected error 
codes from PUT method.
Comment 3 Alejandro Alvarez 2011-05-25 07:35:03 UTC

It has been a long time since this was reported, and now I am hitting the same problem as Mark.
In our case, the return code we want to submit is 301, which is explicitly defined in the HTTP RFC for PUT methods. If WebDAV extends, shouldn't mod_dav support it?

Patching this is trivial, but distributing our own patched version is not ideal, though.

Comment 4 William A. Rowe Jr. 2011-05-25 12:51:28 UTC
Basant's patch looks right, although is it necessary to avoid 200 responses in that logic?
Comment 5 Alejandro Alvarez 2011-05-31 12:18:20 UTC
Probably yes, as other calls need to be called in that case (seek, write, close), and 20x statuses are already managed by mod_dav.

I suppose just a condition like this would do:

if ((err = (*resource->hooks->open_stream)(resource, mode,
                                                &stream)) != NULL) {
        int status = err->status ? err->status : HTTP_FORBIDDEN;
        if (status > 299)
            err = dav_push_error(r->pool, status, 0,
                                          "Unable to PUT new contents for %s.",
                                           ap_escape_html(r->pool, r->uri)),
            err = NULL

True unexpected return codes may result. But I would say that's the developer's problem, not mod_dav's

Any hope of this being fixed?
Comment 6 Ricardo Rocha 2011-10-21 16:08:19 UTC

Any news on this one?

It would be great to get this in, Alejandro's suggestion looks ok?

We also need to return 301, and are currently shipping a patched mod_dav for this.

Comment 7 Alejandro Alvarez 2013-03-01 14:40:45 UTC

Any news on this?

Comment 8 Graham Leggett 2013-04-30 15:29:55 UTC
Fix committed to trunk in r1477687.

Can you verify that this fix works for you? If so, it can be backported to v2.4.
Comment 9 Alejandro Alvarez 2013-05-06 12:25:08 UTC

I confirm the fix works. Any change of it being backported to 2.2? Currently we support RHEL5 and 6, where the version is 2.2.

Comment 10 William A. Rowe Jr. 2018-11-07 21:09:01 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.