You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ed Korthof <ed...@organic.com> on 1998/02/05 21:01:21 UTC

[PATCH] http_protocol (was Re: case insensitive, multi-line headers)

Sorry 'bout missing the case-insensitivity & the way multi-line headers
are handled. <rueful>

I'd like to fix the actual bugs Marc and Dean described, as I have some
free time on my hands.

So far as fixing the 408 -> 414 problem, we could set the status to
HTTP_OK if it's currently 408 (we'd just do this in the sections where
we're reading headers and we're about to return a 414 error to the client
anyway, so this wouldn't mess up other parts of the code & vice versa),
and then die() with an appropriate error.  So far as I can see, it really
is true that other than timeouts and the potential to return an error
while reading the headers, there's no way we'll have to worry about
r->status being set to HTTP_REQUEST_TIME_OUT. 

There are, of course, other ways to do the HTTP_REQUEST_TIME_OUT thing,
and perhaps it'd be worthwhile to change it.  I dunno.  Each of the other
solutions I heard when we last went over this had it's own set of
problems...

Anyway, I put together a patch to fix some the problems Marc described
(without changing how we handle HTTP_REQUEST_TIME_OUT) and the one Dean
described.  So far as the latter problem is concerned, I wrote the patch
to keep pulling data and discard it.  It'd certainly also be possible to
have it return a 400 error or pull in all the data and then combine it; 
I'd be happy to reimplement this either of those ways. 

In this patch, I have set it up to log failures in the access log as well
as in the error log.  Also, if run_post_read_request() returned something,
the request would be killed (via die()), but it wouldn't be logged.  I've
changed that as well... it seems we should log such stuff.

Clients who trigger 400, 408, and 414 errors generally don't see the error
itself, though it will be logged.  That might be worth fixing...

Comments are welcome, as always.

This is only lightly tested, though it does appear to work fine.

     -- Ed Korthof        |  Web Server Engineer --
     -- ed@organic.com    |  Organic Online, Inc --
     -- (415) 278-5676    |  Fax: (415) 284-6891 --

On Wed, 4 Feb 1998, Marc Slemko wrote:

> Yes.  This is mixed in with a bunch of other brokenness in this area (eg.
> logging 408 (timeout) for a 414 (URI too large) that I ranted on a bit
> ago.  Unfortunately, I'm swamped right now.  Sigh.  Perhaps next year.
>
> On Wed, 4 Feb 1998, Dean Gaudet wrote:
> > On Wed, 4 Feb 1998, Dean Gaudet wrote:
> > > Look at getline() we handle multiline headers.
> > 
> > Although there's an obvious bug.  If there's a line that exceeds the
> > buffer size then we bail without reading the rest of the line and any
> > possible continuation lines.  So we'll treat the rest of the line as if
> > it's a new line.  Bad. 
> > 
> > Dean