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,
I'm afraid this is true... Does anyone else have a better idea?
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).
No, just modify the protocol data... If you want to insert a specific header field, just construct the text form of it as if the brower sent it and return it to the filter on top at the right point in the data stream. You're going to be keeping up with data you've read anyway so you can return it at the right time to the calling filter. Be careful you have configuration to avoid buffering the entire .iso file that somebody tries to copy to their DAV filesystem. And your configuration may be roll-your-own w.r.t. selecting which request objects to operate on since you may have to make your decisions before Apache has read the entire request header.
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.
The simple answer is that if you return data in the right format to HTTP_IN, then there won't be a problem :) But keep track of Apache 2 development in that area so that if the interface has to change between those filters you can accomodate. I'm doubtful that the exact division of labor between the different Apache-provided input filters can be considered a stable programming interface.
