httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton" <graham.dumple...@gmail.com>
Subject Reading of input after headers sent and 100-continue.
Date Wed, 30 Jan 2008 00:28:46 GMT
A question about HTTP output filter 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:

        /* Since we're about to read data, send 100-Continue if needed.
         * Only valid on chunked and C-L bodies where the C-L is > 0. */
        if ((ctx->state == BODY_CHUNK ||
            (ctx->state == BODY_LENGTH && ctx->remaining > 0)) &&
            f->r->expecting_100 && f->r->proto_num >= HTTP_VERSION(1,1))
{
            char *tmp;
            apr_bucket_brigade *bb;

            tmp = apr_pstrcat(f->r->pool, AP_SERVER_PROTOCOL, " ",
                              ap_get_status_line(100), CRLF CRLF, NULL);
            bb = apr_brigade_create(f->r->pool, f->c->bucket_alloc);
            e = apr_bucket_pool_create(tmp, strlen(tmp), f->r->pool,
                                       f->c->bucket_alloc);
            APR_BRIGADE_INSERT_HEAD(bb, e);
            e = apr_bucket_flush_create(f->c->bucket_alloc);
            APR_BRIGADE_INSERT_TAIL(bb, e);

            ap_pass_brigade(f->c->output_filters, bb);
        }

Now, if one is generating response content prior to having read any
input, if one hasn't buffered the response output, by virtue of
explicitly flushing it in some way, this will trigger any response
headers which have been set up to be sent.

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.

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.

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.

This is occurring when testing with Apache 2.2.4.

Any ideas appreciated.

Graham

Mime
View raw message