Hi, I am writing a module need to be able to examine POST data, and insert inbound HTTP request headers after my code has been run by apache so that:
1. the web application can still retrieve the POST data if required for its own consumption 2. the web application needs to have access to the HTTP inbound request headers generated at runtime (mod_header can't help me) by my code. A web application in this case could be one of the following (not exhaustive): * a native apache 2.0 module * mod_jk with Tomcat on the back end actually running the application * mod_cgi/mod_cgid * mod_proxy (the back web webserver will act as the web application) Attempted Solution Use an input filter. This provides the mechanism to examine the POST data at my will without consuming it off the socket, thus giving the web application still the opportunity to consume it. The input filter chain happens during the handler phase, and is triggered if either of the following is true: 1. there is an explicit call by the web application to read the POST data (either calling the ap_XXX_client_block() series API or ap_get_brigade()) 2. in the case where the web application doesn't care about the POST data (but still requires the inbound HTTP request headers that my code creates), it is the ap_finalize_request_protocol() that triggers the input filter chain. This is most likely a special case, since if the web application doesn't care about the POST data, a GET would be more appropriate. Problem Let's say that the web application, before executing its own logic, needs to check for a HTTP request header that I generate to decide if it should proceed or not. So unless the web application tries to consume the POST data, my code (in the input filter) will never get the chance to run to insert those inbound HTTP request headers that the application requires. Question Is there a work around for the above solution in order to avoid the above problem, in order: 1. for my code to be able to examine the POST data and still allow the web application to consume it, and 2. for my code to be able to insert those inbound HTTP request headers so that the web application can see them at run time, without putting the constraint on it to have to retrieve the POST data first to have access to those inbound HTTP request headers? An example would be a cgi application that relies on mod_cgi. mod_cgi first reads the HTTP request headers before reading the POST data (add_common_vars() is called way before ap_get_brigade() in cgi_handler()). So that means the cgi application will never get the chance to see the headers that my code inserted. Once ap_get_brigade() returns, the headers will be set, but add_common_vars() has already been executed. Since I need to be able to peek at the POST data without consuming it, the input filter is the only known solution (right?).Is there a known work around this? The only way I can see where I will have the ability to insert those HTTP inbound request headers is if my filter runs between the CORE_IN and the HTTP_IN input filter, in which case I will need a properly populated request_rec* structure to be able to use the ap_XXX APIs (typical things would be get the mime-type, content-length of the POST data, protocol version, etc). Since my filter will run before the HTTP_IN filter would have had a chance to parse the request line and the request headers, it will most likely cause confusion within the Apache internal state. Any other ideas? Thanks, -Alberto
