Bug 35981

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.

This issue still exists in HTTPD 2.4 and it would be great to have it fixed!

Perhaps the simplest use case is PUT-ting a file into a non-existing directory (mod_dav_fs).
According to the WebDAV specification, the server should return a 409 Conflict [RFC 4918, sec 9.7.1] and although the 409 is returned by mod_dav_fs, it is overwritten at this point with a 403.

I cannot speak to the full correctness of the implemented fix, but r1477687 does look like it properly addresses the problem.
Please let me know if I can help getting the fix backported.

Proposed for backport in r1906383.

Backported as r1906393.