On Fri, Oct 18, 2019 at 2:37 PM Ruediger Pluem <[email protected]> wrote:
>
> On 10/18/2019 01:50 PM, Yann Ylavic wrote:
> >
> > I thought about it but if the client somehow sent both the header
> > (with "Expect: 100-continue") and the body altogether, we have the
> > body prefetched already and spool_reqbody_cl() will not call
> > stream_reqbody_read(), thus HTTP_IN filter.
>
> Correct. But in this case we could sent the final status code directly or we
> sent a 100 continue before.
> IMHO it does not matter. At least this my read of
> https://tools.ietf.org/html/rfc7231#section-5.1.1
Fair enough. I finally went for:
/*
* Tell the HTTP_IN filter that it should send a "100 continue" if the
* client expects one, before blocking on the body, otherwise we'd wait
* for each other.
*/
if (req->expecting_100) {
/* From https://tools.ietf.org/html/rfc7231#section-5.1.1
* A server MAY omit sending a 100 (Continue) response if it has
* already received some or all of the message body for the
* corresponding request, or if [snip].
*/
r->expecting_100 = APR_BRIGADE_EMPTY(input_brigade);
req->expecting_100 = 0;
}
such that we are fine with further processing (and the RFC).
Thanks for the review Rüdiger!
Regards,
Yann.
