httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: [users@httpd] 100-continue response when 401 expected - Apache 2.2.26
Date Wed, 17 Oct 2007 08:38:44 GMT
On Tue, 16 Oct 2007 14:42:40 -0700
"Ragini Bisarya" <ragini.bisarya@gmail.com> wrote:

> I would like to clarify that the client does not know if the web

Yes, I understand what you're saying.  That was clear enough first
time.  And just to be clear, I believe you're probably right that
there is a problem.  But you didn't tell the whole story.

> > 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.

But you didn't explain where in your overall setup the 401 is
generated, and therefore whether or not the server needs the
request body before it can deduce whether the request is accepted.

> 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).

Yep.  So tell us *exactly* what should cause the 401, so we can tell
when it *should* happen.

> 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.

Without a content-length (or transfer-encoding) it knows there cannot
be a request body, so it doesn't ask for one.  This fits with the
suspected-bug you're reporting, though it's still not certain proof.

> 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.

Ugh.  That should be a 400 (Bad Request) error.  Is your script
being run, or is Apache generating the error without running the
script?

> <HEAD><TITLE>Error</TITLE></HEAD><H1>Error Publishing File</H1>
> An error occurred publishing this file (Content-Length missing or
> zero ()).

Hmmm, that's not Apache, so it's either your script or a custom
ErrorDocument.

> > > 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.

You tested "it sends 401 when it should send 401".
You didn't test "it doesn't send 401 when it should send 100".

> > 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.

OK, now you're telling us.  Not that it really matters: I just
sometimes get fussy about incomplete reports.

> Sorry if I am repeating the same thing in many more words. I hope I am
> getting my point across.

Indeed, thanks for the report.

Can I suggest your best course of action now is to enter it into
our bugzilla at http://issues.apache.org/ ?  I *think* the root
cause of this is related to bugs 16518 and 19442 and an old/
incorrect fix to them (see Comment 14 on bug 16518).  But your
bug is clearly not the same as those, and needs a new report.

-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

---------------------------------------------------------------------
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