www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Smith <csm...@smith-family.com>
Subject Re: general/6548: Apache treats an HTTP 1.1 PUT request as a GET in some cases
Date Tue, 19 Sep 2000 02:20:04 GMT
The following reply was made to PR general/6548; it has been noted by GNATS.

From: Christian Smith <csmith@smith-family.com>
To: Cc: apbugs@Apache.Org
Subject: Re: general/6548: Apache treats an HTTP 1.1 PUT request as a GET in some cases
Date: Mon, 18 Sep 2000 22:22:01 -0400

 On Monday, September 18, 2000 at 22:08, fanf@apache.org (Tony Finch) wrote:
 > Christian Smith <csmith@smith-family.com> wrote:
 > >On Monday, September 18, 2000 at 21:02, fanf@apache.org wrote:
 > >
 > >> Apache leaves a lot of the correct handling of different HTTP methods
 > >> (GET, POST, PUT) to CGIs. I.e. your CGI is not handling the PUT correctly.
 > >> If you are trying to use PUTs to publish CGI scripts then it sounds like
 > >> mod_put isn't going to solve your problem.
 > >
 > >I'm not convinced that this is the case. It looks to me like the PUT request
 > >is not being passed to mod_put at all
 > Correct.
 > >and that Apache is handling the PUT request as a GET. 
 > No, the CGI is handling the PUT as if it were a GET. Your example of a
 > server without mod_put illustrates this.
 That doesn't compute. What about the case where one tries tp PUT to a URI
 which doesn't point to an exiting file. The server returns an error 404. You
 can not possible tell me that the CGI is handling the PUT as a GET because
 the CGI does not exist.
 > >This is an Apache bug, not a mod_put bug.
 > No, it's a deliberate feature -- otherwise CGIs would be considerably
 > less useful.
 Perhaps "deliberate mis-feature". Seems to me the RFC is pretty clear on
 what is supposed to happen when a PUT command is received and it is pretty
 clear that Apache is NOT doing the right thing and is therefor NOT compliant
 with RFC 2068.
 Further more, RFC 2068 says
 > The PUT method requests that the enclosed entity be stored under the
 > supplied Request-URI. If the Request-URI refers to an already existing
 > resource, the enclosed entity SHOULD be considered as a modified version
 > of the one residing on the origin server. If the Request-URI does not
 > point to an existing resource, and that URI is capable of being defined as
 > a new resource by the requesting user agent, the origin server can create
 > the resource with that URI.
 Under this definition the current behaviour for an existing file and a file
 which does not exist are both broken. You simply can not justify the current
 behaviour as a feature as it violates RFC 2068.
 Please fix.

View raw message