Bug 35981 - mod_dav overrides dav_fs response on PUT failure
Summary: mod_dav overrides dav_fs response on PUT failure
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_dav (show other bugs)
Version: 2.0.54
Hardware: All All
: P2 major with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate, PatchAvailable
Depends on:
Blocks:
 
Reported: 2005-08-02 21:06 UTC by Mark Rinfret
Modified: 2018-11-07 21:09 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
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,
                         message);

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,
                             apr_psprintf(r->pool,
                                          "Unable to PUT new contents for %s.",
                                          ap_escape_html(r->pool, r->uri)),
                             err);
    }
Thus, we are getting FORBIDDEN at the client when we want 
HTTP_UNSUPPORTED_MEDIA_TYPE.
Comment 1 Basant Kumar Kukreja 2007-03-07 09:48:15 UTC
RFC 2518
http://asg.web.cmu.edu/rfc/rfc2518.html
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
open_stream.
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,
                              apr_psprintf(r->pool,
                                           "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
Hello,

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.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6
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,
                                   apr_psprintf(r->pool,
                                          "Unable to PUT new contents for %s.",
                                           ap_escape_html(r->pool, r->uri)),
        else
            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
Hi.

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.

Thanks,
  Ricardo
Comment 7 Alejandro Alvarez 2013-03-01 14:40:45 UTC
Hello,

Any news on this?

Regards.
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
Hi,

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.

Regards.
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.