httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <>
Subject [PATCH] Move http header parsing into the http_input_filter
Date Mon, 24 Feb 2003 17:21:10 GMT
This patch trims about 2500 instructions out of the path between 
ap_read_request and ap_graceful_stop_signalled when handling a simple 
GET request (will post some profiles in a few minutes).  The patch 
demonstrates some primary principles but is still far from complete. 
POST requests will certainly fail, as will pipelined requests, but the 
basic framework is complete enought to allow these to be fixed without 
requiring major rewriting of code.

Quick Overview and Interesting (controversial) Design Points
1. HTTP header parsing moved out of protocol.c and into the HTTP_IN 
filter (ap_http_filter in http_protocol.c)
2. HTTP_IN is now nearly purely state driven. ap_http_filter registers a 
cleanup on the request pool that drives the filter to the 'new request' 
3. A pointer to the current request req is placed in the conn_rec for 
use by ap_http_filter
4. New function, ap_brigade_getline() replaces 
ap_get_brigade(AP_MODE_GETLINE). This new function has some interesting 
- You can pass -in- a brigade to the function.
- If you pass in an empty brigade, it will issue 
ap_get_brigade(AP_MODE_READBYTES) to fetch bytes from lower level filters
- User of this function must be prepared to setaside the portion of the 
brigade not immediately needed (eg, the second request in a pipelined 
request in http_input_filter_ctx_t)

I generally like the idea of putting protocol parsing in a connection 
level filter. I think this is a more straight forward way to use the 
Apache 2 infrastructure to handle protocols.

Issues to resolve:
1. net_time_filter sits on top of the HTTP_IN filter. I have given this 
zero thought but it may need to repositioned to sit below HTTP_IN.
2. Lots of broken error paths.
3. Need to implement and debug code to handle pipelined requests and 
request bodies (chunked, unchunked, etc).
4. Formally address (by API changes?) the notion of a PROTOCOL filter 
that lasts the duration of a connection
5. Reevaluate what services should be provided by the core_input_filter 
vs http_in (or any other protocol) filter.


View raw message