httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Rothe <>
Subject Re: Change the content-length header for other filters
Date Thu, 22 Dec 2016 14:05:24 GMT

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);

There the content-length header will be used to allocate a buffer for 
the content and the method reads the body content by


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

 Von:   Nick Kew <> 
 An:   <> 
 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 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message