On 10/20/2019 04:52 PM, Yann Ylavic wrote:
> Hi Rüdiger,
>
> On Sat, Oct 19, 2019 at 4:04 PM Yann Ylavic <[email protected]> wrote:
>>
>> /*
>> * 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;
>> }
>
> I had to revert this, the HTTP_IN filter won't handle "100 continue"
> anymore after prefetching..
> So back to this r1868576, plus r1868653 to handle
> rfc7231#section-5.1.1's MAY directly in ap_proxy_http_prefetch(), when
> we know we have some body bytes.
>
> Looks good to you?
Sorry for getting back late. I missed that the HTTP_IN filter only sends a
possible
100 continue during the first run. Good catch. Nevertheless this leaves the
question open
how to solve this. Either by your patch which sends the intermediate response
itself
or by fixing HTTP_IN to check for the need to sent it not only on the first run.
I am undecided. Maybe someone else has a strong opinion either way otherwise
just move on with your patch.
Regards
Rüdiger
