httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andre Rothe <andre.ro...@zks.uni-leipzig.de>
Subject Re: Change the content-length header for other filters
Date Thu, 12 Jan 2017 23:04:56 GMT
Hi,

I have looked into the ap_get_client_block(), it uses the brigade api too. 
If I would remove the old api calls from mod_WebObjects, how many bytes 
I should read on every call to ap_get_brigade (BLOCK_READ)? Is it necessary
to define a timer, which stops a block read, if I try to read too many bytes? 
Or should I use NONBLOCK_READ?

My last try was, to get only one byte from the client first and then read the 
content-length header again (in the case, that it has been changed by my filter) 
and call ap_get_client_block() with the corrected length again. 

But I learned, that my filter collects all bytes of the request body (the brigade 
contains EOS then) to process it and a second call to ap_get_client_block() returns 
always 0, because req->remaining = 0.

I don't see a chance to implement my filter at the moment. Is it possible to use 
mod_proxy? A second server in front of the WebObjects server could re-send the
browser requests with mod_proxy which calls my filter too. Maybe with

SetEnv proxy-sendcl 1

the Content-Length header could be fixed after the filter, just before resend the
request to the backend server (WebObjects). But I have to change all response links 
(HTML, CSS, Javascript) with mod_proxy_html from the WebObjects server to the proxy.
But this is so much overhead to intercept and change a simple request.

Any further ideas?

Thanks a lot
André


 Von:   Eric Covener <covener@gmail.com> 
 An:   <modules-dev@httpd.apache.org> 
 Gesendet:   22.12.2016 14:43 
 Betreff:   Re: Change the content-length header for other filters 

On Thu, Dec 22, 2016 at 8:37 AM, Andre Rothe 
<andre.rothe@zks.uni-leipzig.de> wrote: 
> I don't know, how mod_webobjects will read the request content, 
> but it seems, that my changes on the request are not transparent. 
> It is not a problem of the transmitted data, it is a length problem 
> (if I don't change the content length, the request will be processed). 
 
 
It uses the old ap_get_client_block() interface instead of using the 
bucket brigade directly.  It does appear to copy the content length 
before the first read is performed [meaning your input filter has not 
run for the first time when it looks at the length). 
 
 
--  
Eric Covener 
covener@gmail.com 

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