On Mon, 9 Apr 2001, Graham Leggett wrote:
> Hi all,
>
> I traced the problems I was having with apr_bucket_read() returning an
> empty string instead of the next line of LF terminated ASCII to a
> problem in the line-at-a-time behavior of HTTP_IN.
>
> If some text was read in, and the terminating LF character was the last
> character in the bucket, the filter would still split this bucket,
> producing the original bucket followed by an empty bucket.
>
> The first text bucket got sent back in response to the request, but the
> rogue empty bucket was placed at the head of the queue to be fetched at
> the next request. The next time apr_bucket_read() was called, this empty
> bucket was returned, and the calling function saw an empty line instead
> of the next line as expected.
>
> In theory the bug really exists with the calling function -
> apr_bucket_read() should be called multiple times until the LF is found.
> However it is usually safe to assume that the first time
> apr_bucket_read() is called the first piece of data should be returned,
> not an empty bucket. This could confuse module authors down the line (it
> sure confused the hell out of me...).
This is a bug in your filter. You must continue to call apr_bucket_read,
until you find the LF. You have been assuming that you will always get an
entire string in one bucket. This is not the case.
Think of a very slow connection, it is likely to send small chunks of data
at a time. There are also some telnet programs that will send data one
char at a time. In either of these cases, your module will recieve a
single brigade that has multiple small buckets. Your filter can not
assume that a full line of data will be sent as one bucket.
Ryan
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
