httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@gonzo.ben.algroup.co.uk>
Subject Re: [PATCH] must flush for CRLFs after POSTs
Date Tue, 28 Jan 1997 10:16:44 GMT
David Robinson wrote:
> 
> On Tue, 28 Jan 1997, Dean Gaudet wrote:
> 
> > Here's a patch to deal with the problem Alexei brought up regarding
> > clients sending an extra CRLF after a POST which isn't included in the
> > Content-Length.  It tweaks buff.c so that it knows to flush the output
> > buffer if a read() would block.  read_request_line() activates this
> > B_SAFEREAD mode while eating CRLFs before a request header.
> > 
> > This has been very lightly tested.  Emphasis on light.  I just thought I'd
> > get it to the list because it sounds like this might be a serious problem.
> 
> I think this patch is an awful hack.
> If the problem is that some browsers send an extra CRLF after POST data,
> then why not explicitly code around this, instead of make the whole of
> buff.c harder to maintain.
> 
> I suggest that mod_cgi should attempt to read any unwanted CRLF pairs after
> having read content-length bytes. To achieve this, you simply need a
> routine in buff.c that attempts to read without blocking.
> 
> /*
>  * Reads up to nbyte bytes of data from the stream without removing data 
>  * from the stream. It only returns the data that is either in the
>  * user buffer or is available in the OS buffers.
>  *
>  * Returns the number of bytes available, 0 for EOF or none- vailable,
>  * -1 for error.
>  */
> int
> brd_peek(BUFF *fb, void *buf, int nbyte)
> {
> 
> /*
>  1. check for an earlier error on the stream.
>  2. If the stream has read-buffering, then copy data out of the buffer into
>     buf.
>  3. If the buffer is not full, use select() or poll() to 
>     test for incoming data, and recv(,,MSG_PEEK) to extract a copy of it.
> */
> }
> 
> Then mod_cgi simply uses brd_peek() to see if there is any extra data, and
> if so it calls bread() to read it.
> 
> This routine can also replace any use of btestread() 
> brd_peek(fb, buff, 1) > 0  tests for available data.
> 
>  David.

Surely this isn't going to work well - what happens if the extra CRLFs are
delayed?

Cheers,

Ben.

-- 
Ben Laurie                Phone: +44 (181) 994 6435  Email: ben@algroup.co.uk
Freelance Consultant and  Fax:   +44 (181) 994 6472
Technical Director        URL: http://www.algroup.co.uk/Apache-SSL
A.L. Digital Ltd,         Apache Group member (http://www.apache.org)
London, England.          Apache-SSL author

Mime
View raw message