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.
I think at some point the "100 continue" will be sent (e.g. when
"forwarding" the one from the backend), but I felt that leaving
r->expecting = 1 until then was asking for troubles (possibly)...
>
> So
>
> /*
> * 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) {
> r->expecting_100 = 1;
> req->expecting_100 = 0;
> }
That would be nicer, though :/
Regards,
Yann.
