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.
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.
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.
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
Basant's patch looks right, although is it necessary to avoid 200 responses in that logic?
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?
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
Hello, Any news on this? Regards.
Fix committed to trunk in r1477687. Can you verify that this fix works for you? If so, it can be backported to v2.4.
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.
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.