httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Smith" <>
Subject RE: Reading of input after headers sent and 100-continue.
Date Thu, 31 Jan 2008 02:50:40 GMT

> -----Original Message-----
> From: Graham Dumpleton [] 
> Sent: Tuesday, January 29, 2008 4:29 PM
> To:
> Subject: Reading of input after headers sent and 100-continue.
> The HTTP output filter will send a 100 result back to a 
> client when the first attempt to read input occurs and an 
> Except header with 100-continue was received. Ie., from 
> http_filters.c we have:
> if ((ctx->state == BODY_CHUNK ||
>   (ctx->state == BODY_LENGTH && ctx->remaining > 0)) &&
>   f->r->expecting_100 && f->r->proto_num >= HTTP_VERSION(1,1))

This is from ap_http_filter(). If you look at http_core.c, you can see
that it is registered as an input filter, not an output filter. So, if
you never read from the input brigade, the "100 continue" will never be
sent. I'm not sure if the module needs to just ignore the input brigade,
or actively throw it away, though.

> The problem then is if only after having sent some response 
> content and triggering the response headers to be sent one 
> actually goes to read the input, then the HTTP output filter 
> above is still sending the 100 status response string. In 
> other words, the 100 response status string is appearing in 
> the middle of the actual response content.

"Doctor, it hurts when I do this!" :)

If a module is sending a response before a 100 continue has been sent,
then it shouldn't read from the input brigade, because it is going
against the HTTP spec. 

> My question then is, what should a handler do if it is trying 
> to generate response content (non buffered), before having 
> attempted to read any input, ie., what is the correct way to 
> stop Apache still sending the 100 status response for the 
> 100-continue header? I know that setting r->expecting_100 to 
> 0 at time that first response content is being sent will 
> prevent it, but is there something else that should be done
> instead?

Since ap_http_filter is an input filter only, it should be enough to
just avoid reading from the input brigade. (AFAICT, anyway.)

> BTW, this is partly theoretical in that have no actual code 
> that is doing this, but technically in systems like 
> mod_python or mod_wsgi where one doesn't know what the Python 
> application code running on top is doing, a user could 
> trigger this situation.

The module can provide an interface to the input and output brigades
that prevents the application from doing this. mod_wsgi is doing this
already. As I mentioned on the Web-SIG list, it is difficult to have an
uniform, automatic mechanism for doing this for all request methods, or
even a uniform way of doing it for a particular method. So, it basically
has to be left up to the handler/application.

- Brian

View raw message