On 10/18/2019 01:50 PM, Yann Ylavic wrote:
> On Fri, Oct 18, 2019 at 10:29 AM Ruediger Pluem <[email protected]> wrote:
>>
>> On 10/18/2019 09:50 AM, [email protected] wrote:
>>>
>>> + /* Send "100 Continue" now if the client expects one, before
>>> + * blocking on the body, otherwise we'd wait for each other.
>>> + */
>>> + if (req->expecting_100) {
>>> + int saved_status = r->status;
>>> +
>>> + r->expecting_100 = 1;
>>> + r->status = HTTP_CONTINUE;
>>> + ap_send_interim_response(r, 0);
>>> + AP_DEBUG_ASSERT(!r->expecting_100);
>>> +
>>> + r->status = saved_status;
>>> + req->expecting_100 = 0;
>>> + }
>>
>> Why sending it directly and not just set r->expecting_100 = 1; and let the
>> HTTP_INPUT filter do the job?
>
> 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
- Requirements for servers.
And even if you are worried I guess we could do
/*
* Tell the HTTP_INPUT 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 && APR_BRIGADE_EMPTY(input_brigade)) {
r->expecting_100 = 1;
req->expecting_100 = 0;
}
Regards
Rüdiger
