Re: Chunked request

[Yann Ylavic]

Hi,

On Fri, Sep 23, 2016 at 12:59 PM, André Rothe
 wrote:
>
> Any ideas?

It depends on whether your filter is called in blocking or
non-blocking mode, i.e. the apr_read_type_e parameter value (either
APR_BLOCK_READ or APR_NONBLOCK_READ).

In the former case, your filter won't return anything upstream until
it has read (and set aside) the whole body (that's its requirement,
AIUI), even if it takes multiple reads downstream.
Then, when the filtering is done, the bucket brigade where each read
bucket has been set aside can be returned in a one go (including the
EOS).

In the latter case (non-blocking), the filter has to read non-blocking too.
If it gets EAGAIN (or any real error), it returns it upstream.
If it gets data, it can set them aside, returning EAGAIN until EOS.
Once EOS, still the whole set aside thing (including the EOS) in a one go.

Hope this helps.

Regards,
Yann.

Chunked request

[André Rothe]

Hi,

I try to understand an request filter (input). Maybe you can help me to
understand the processes:

The POST size of a request is larger than 8192 bytes, so the request
will be split up into two pieces. I need both parts to process the
request within the filter. There are further filters, which process the
request too.

My filter calls ap_get_brigade() and tries to get the bytes. The brigade
will be stored within a context structure of the ap_filter_t.

On the first call of my filter it gets only 8192 bytes and no EOS. As
the next, I'm looking for EOS, if there isn't one, I try to store the
buckets with

apr_bucket_setaside(b, f->r->pool);

and return from the filter with APR_SUCCESS. I think, there should be a
further call of my filter hook with the second chunk. There I would
concat the stored brigade with the new one. If there isn't an EOS too,
store the whole brigade again. But is there an EOS, I can process the
request.

What I have to send on the first call to the next filter (nothing,
flush)? At the moment I get an

Sending error response: The request contained fewer content data than
specified by the content-length header

within the error_log and the client gets a 404. So it seems, that a
filter should be informed, that my filter waits for further chunks and
passes the chunks together to the next filter after the second call.

Any ideas?

Thank you.
Andre