httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: httpd-2.0 CHANGES
Date Sat, 29 Sep 2001 13:26:21 GMT
In a message dated 01-09-29 12:55:27 EDT, you write:

> I believe that the AP_MODE_PEEK would actually take care of this.
>  Greg and I were commenting that it eats any blank CRLF pairs after
>  a request.  That's not exactly what it is supposed to do (it is
>  PEEK after all), but it does handle this situation.  The first
>  request wouldn't read that extra CRLF.  When that request is done,
>  we do a PEEK and that eats the CRLFs.  Then, the next request is
>  read.  -- justin

Here's the real 'gotcha' with that...

If pipelined requests have been send and the first one is a huge
POST that uses Transfer-Encoding AND it happens to have a
legitimate 'trailer' then it shows up like this...

POST /something.cgi HTTP/1.1
Yada Yada
CR/LF ( End of header )
First chunk
Next chunk
Last chunk
0 CR/LF ( End of chunked data )
Host:  <- Legal trailer to 'change' Host: field
CR/LF ( End of trailers ) 
CR/LF ( Possible out-of-band blank line added by Netscape )

If you are relying on your 'peek' routine to pull blank CR/LF's
then here is what happens if it doesn't know for SURE if there
are supposed to be any trailers...

1. It does NOT see a blank CR/LF after the '0 CR/LF' end of 
chunked data so it leaves the 'Host:' trailer in the input stream
and now this looks like the start of the next pipelined header.
It is not.

2. The logic handling the next 'pipelined' request just sees
the trailer as the start of the next HTTP request and what was
the blank CR/LF that ended trailers as a legal EOH ( End of header ).
Since it might actually contain a 'Host:' field then it will pass muster
as a valid request unless the front door logic sees that there
is actual valid 'request' line with 'GET/POST/HEAD' whatever'.

3. The trailer floats down the pike as a 'valid' HTTP/1.1 request.

4. The request will be rejected by someone ( probably ) and only
now is the original Netscape 'out of band' CR/LF available to 
'peek' since the one before it was interpreted ( erroneously ) to
be the legal 'EOH' for the next pipelined request.

So yeah... 'peeking' the 'out of band' CR/LFs will work as
advertised but if you missed a REAL trailer on the first
request then a bad request gets 'inserted' into the stream

Essentially the whole 'trailers' scheme and the use of
blank lines to end it needs to be tossed. Should have 
never been done that way in the first place but I guess
it's a little late to go back now.

There should have been an absolute 'End of chunking'
signal ( other than a BLANK LINE ) that was ALWAYS 
required to be there whether there were any trailers or not.

Kevin Kiley

View raw message