Bug 50336 - PUT failures do not emit Allow:
Summary: PUT failures do not emit Allow:
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.2.15
Hardware: PC Linux
: P2 minor (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2010-11-25 07:11 UTC by Christopher Yeleighton
Modified: 2018-11-07 21:08 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Yeleighton 2010-11-25 07:11:20 UTC
I have set a scratch directory writable by everybody.  

drwxr-xr-x 2 wwwrun www 4096 11-24 22:28 /tmp/www

Alias /scratch "/tmp/www"
<Directory /tmp/www>
 Allow from all
 Order Allow,Deny
</Directory>


I created /tmp/www/test.txt and GET /scratch/test.txt works.

However, the following command does not work:

curl -k -T ./test.html https://server/scratch/

HTTPd returns Error 403, with the following explanation:


    The PUT
    method is not allowed for the requested URL

So far so good, although not exactly what I wanted.

The request is reported in /var/log/apache2/access_log
BUT 
The error is not reported in /var/log/apache2/error_log!
Even after I set LogLevel to debug!

WHY?

Software: 

Name        : apache2                      Relocations: (not relocatable)
Version     : 2.2.15                            Vendor: openSUSE
Release     : 3.7                           Build Date: pon, 5 lip 2010, 17:17:44
Comment 1 William A. Rowe Jr. 2010-11-29 23:26:32 UTC
Because the core handler rejects unrecognized methods, and you have that data in the access log, as you note.  403 is an unambiguous response, and there is nothing more for the core handler to tell you.
Comment 2 Christopher Yeleighton 2010-11-30 08:50:44 UTC
HTTPd returns Error 403, with the following explanation:


    The PUT
    method is not allowed for the requested URL

That means the PUT method is recognised but not allowed.
The messsage suggests that it is a policy-related issue.  
Otherwise, the error message would be:

    The PUT
    method is not recognised for the requested URL

BTW, I would like to express my surprise with your supposition that the PUT method need not be recognised.  It is a standard method.  E.g. Jigsaw uses this fact as a justification for not supporting multipart/form-data.

So, if given that you are unwilling to log it as an error for some reason, 
please fix the error message at least.
Comment 3 William A. Rowe Jr. 2010-11-30 11:15:55 UTC
METHOD_NOT_ALLOWED reflects the fact that there is no PUT handler distributed
with httpd, other than mod_dav.

Which raises a question; was mod_dav loaded?  Enabled?  Supported by another
module or script?
Comment 4 Christopher Yeleighton 2010-11-30 12:09:30 UTC
(In reply to comment #3)
> METHOD_NOT_ALLOWED reflects the fact that there is no PUT handler distributed
> with httpd, other than mod_dav.
> 
> Which raises a question; was mod_dav loaded?

No.

>  Enabled?

No.

>  Supported by another module or script?

No AFAICT, but HTTPd is complex enough not to be sure.

Thanks for reconsidering.
Comment 5 William A. Rowe Jr. 2010-11-30 12:36:47 UTC
Then I concur, this result code was wrong.

FWIW; "Jigsaw uses this fact as a justification for not supporting multipart/form-data."
One has nothing to do with the other, PUT is unrelated to this HTML-ism.
Comment 6 Christopher Yeleighton 2010-11-30 14:05:17 UTC
(In reply to comment #5)
> FWIW; "Jigsaw uses this fact as a justification for not supporting
> multipart/form-data."
> One has nothing to do with the other, PUT is unrelated to this HTML-ism.

Premises:
  1. multipart/form-data exists mainly to permit file upload.

  2. 
Customers can just PUT their files to Jigsaw, and it is more appropriate for them to do so according to the HTTP specification. 


Conclusion: Jigsaw need not support multipart/form-data.

That was the gist of the argument.
Comment 7 Christopher Yeleighton 2010-11-30 17:23:05 UTC
(In reply to comment #5)
> Then I concur, this result code was wrong.

The status code is 405 now, not quite sure what has changed.

(In reply to comment #3)
> METHOD_NOT_ALLOWED reflects the fact that there is no PUT handler distributed
> with httpd, other than mod_dav.

This is a peculiar way of saying things, very misleading.  
But that is what the standard says, so I guess it must be like that.

That would invalidate the bug, except for the following detail.
Here are the headers dumped by curl:

HTTP/1.1 100 Continue

HTTP/1.1 405 Method Not Allowed
Date: Tue, 30 Nov 2010 22:14:50 GMT
Server: Apache/2.2.15 (Linux/SUSE)
Vary: accept-language,accept-charset
Accept-Ranges: bytes
Transfer-Encoding: chunked
Content-Type: text/html; charset=iso-8859-1
Content-Language: en


Where is Allow:?

10.4.6 405 Method Not Allowed
 The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:29 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.