Thanks for your response. I would like to clarify that the client does not know if the web resource is protected by authentication or not and if so, does it require Basic or Digest authentication scheme. Therefore the client can never send the authentication header in the initial request. The aim is that the client attempts to send just the PUT request headers without the auth header and without the body. -- If the server requires authentication it will send a 401 and the client can send the request headers with Auth header AND provide the request body. -- If no auth required the server will send a 100 continue and the client will send the request body. Please see my response inline to the points you have raised ... > > For PUT requests with a Expect: 100-continue header, Apache 2.2.6 > > server sends a HTTP/1.1 100 Continue response before checking to see > > if a 401 or 405 response might need to be sent for the request. > > That seems less than optimal, but you didn't really give it a chance. I expected that sending a request without the Authentication header, for a resource that requires authentication, would result in a 401 being returned. Instead I got back a 100 Continue. I was expecting that things that can be checked by the apache infrastructure without requiring the application (in this case the put.cgi) to get involved would be checked before asking the client to continue sending the body. Example - Method allowed or not (405), auth required or not (401). While trying to test for the condition where if a malformed request is sent would I get back a 100 continue or 400 Bad request I noticed a strange thing with 2.2.6. If I do not have the Content-Length header present in the initial request, then I get back a 401 just the way I would like to. Like so... PUT /secret/test.html HTTP/1.1 Host: 10.10.10.1:8080 Expect: 100-continue Date: Mon, 15 Oct 2007 20:05:24 GMT Connection: Keep-Alive HTTP/1.1 401 Authorization Required Date: Tue, 16 Oct 2007 20:52:57 GMT Server: Apache/2.2.6 (Unix) WWW-Authenticate: Basic realm="level_15_access" Content-Length: 401 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 But on including the Content-Length header I get back a 100 Continue. PUT /secret/test.html HTTP/1.1 Host: 10.10.10.1:8080 Expect: 100-continue Date: Mon, 15 Oct 2007 20:05:24 GMT Connection: Keep-Alive Content-Length: 2 Content-Type: application/octet-stream HTTP/1.1 100 Continue Why is the presence of the Content-Length header causing 2.2.6 to not reject the request with a 401? I am really confused about which other headers might cause this? Unfortunately this is not a workable workaround. Because for resources that do NOT require authentication, omitting the Content-Length header results in a 500 Internal error. PUT /test.html HTTP/1.1 Host: 10.10.10.1:8080 Expect: 100-continue Date: Mon, 15 Oct 2007 20:05:24 GMT Connection: Keep-Alive Content-Type: application/octet-stream HTTP/1.1 500 Internal Server Error Date: Tue, 16 Oct 2007 21:12:52 GMT Server: Apache/2.2.6 (Unix) Content-Length: 140 Connection: close Content-Type: text/html <HEAD><TITLE>Error</TITLE></HEAD><H1>Error Publishing File</H1> An error occurred publishing this file (Content-Length missing or zero ()). So I am back to the question of why is it that Apache 1.3 can detect the 401 condition correctly with a request like this PUT /secret/test.html HTTP/1.1 Host: 10.10.10.1:8080 Expect: 100-continue Date: Mon, 15 Oct 2007 20:05:24 GMT Connection: Keep-Alive Content-Length: 2 Content-Type: application/octet-stream whereas Apache 2.2 requires the headers and request body before it will return the 401. > > > Apache 1.3.33 on the other hand, checks for the 401 condition before > > sending a 100 Continue response. It sends a 401 to the client. > > Are you sure? That's not what you tested. My test tried to upload a file to a dir that required authentication. But the request did not contain a Authentication header. The request contained an Expect: 100-continue header. The server correctly realized that it is not OK to continue until the Authentication header is provided and returned a 401. So in the next request the client provided the Authentication header and the entire request body resulting in a successful transaction. > > > Using Apache 2.2.6 > > [chop - is as you describe] > > > Using Apache 1.3.33 > > > > ----------------------------- > > >>> to server > > PUT /secret/test.html HTTP/1.1 > > Host: 10.10.10.1:8888 > > Expect: 100-continue > > Date: Mon, 15 Oct 2007 22:22:24 GMT > > Connection: Keep-Alive > > Content-Length: 49 > > Content-Type: application/octet-stream > > > > <<<from server > > HTTP/1.1 401 Authorization Required > > Date: Mon, 15 Oct 2007 22:22:24 GMT > > Server: Apache/1.3.33 (Unix) > > WWW-Authenticate: Basic realm="secret_access" > > Content-Length: 401 > > Connection: close > > etc... > > So what would've happened if the original request had > included the credentials, or if no authentication was required? For both of those cases Apache 1.3 and 2.2 return 100 Continue and then the Client sends the request body. So no issues there. > If you're claiming 1.3 works better, you need to tell us! Yes. 1.3 works better since it can detect the 401 and 405 error cases before requiring the client to send the request body. Whereas, in the presence of some headers (Content-Length) Apache 2.2 does not. Therefore 1.3 is more optimal for large PUT and POST requests. Sorry if I am repeating the same thing in many more words. I hope I am getting my point across. Thanks, Ragini --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|