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