Hello, I've got the source code of mod_WebObjects, which is the destination module of the request. It registers a handler to process the incoming requests like
ap_hook_handler(WebObjects_handler, NULL, NULL, APR_HOOK_MIDDLE); As I understand the Apache request processing, in this case the content generator is the mod_WebObjects (or the WebObjects Application Server behind it) and my filter (input and output) are placed by mod_ext_filter in the data processing axis. Is it necessary to set mod_WebObjects as successor of mod_ext_filter to define an order within the processing axis too? Within the WebObjects_handler hook the request_rec will be read and the headers_in table will be copied into an own structure with retval = ap_setup_client_block(r, REQUEST_CHUNKED_ERROR); apr_table_do(...); There the content-length header will be used to allocate a buffer for the content and the method reads the body content by ap_get_client_block(...) into that buffer. So it could be, that all of these things are finished in mod_WebObjects during my filter code processes the new length and ap_get_client_block() waits till body data are available (after my filter code). Can I stop the header processing in mod_WebObjects (before apr_table_do()), maybe if I read the bucket brigade till EOS there? It should only be possible after my filter returns APR_SUCCESS, right? In mod_ext_filter I read the whole body before processing, because I will get also an exception, if the request has two or more chunks. So I read all chunks, copy it into one brigade (setaside), process it in the external PHP scripts and send it further as one brigade. This could generate performance issues, but at the moment, the application is still very fast. Thank you André Von: Nick Kew <n...@apache.org> An: <modules-dev@httpd.apache.org> Gesendet: 12/22/2016 2:05 AM Betreff: Re: Change the content-length header for other filters On Wed, 2016-12-21 at 22:10 +0100, André Rothe wrote: > But after my filter completes the request processing, I'll get: > > Sending error response: The request contained fewer content data than > specified by the content-length header Sorin's reply is part of the story, and may or may not be useful in your case. The basic issue you have to consider is that the headers arrive before the body, and a handler that cares about Content-Length is likely to have read it before your filter has reset it. The alternative - read and buffer the entire body before starting to process it - becomes hopelessly inefficient for large requests. There's some discussion of the issue in the mod_proxy docs, as mod_proxy has an option to support HTTP/1.0 backends that need an explicit Content-Length. -- Nick Kew
