httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ragini Bisarya" <ragini.bisa...@gmail.com>
Subject Re: [users@httpd] 100-continue response when 401 expected - Apache 2.2.26
Date Tue, 16 Oct 2007 21:42:40 GMT
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@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message