httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Thu, 21 Sep 2006 09:05:32 GMT

Issac Goldstand wrote:
> In any case, if we're proxying for an HTTP/1.0 client using HTTP/1.1
> (too tired to check if mod_proxy preserves HTTP version - but will try
> to check tomorrow if no one beats me to it), or even serving cached
> content to a 1.0 client originally received by a 1.1 request, we'd have
> to do all this even now, wouldn't we?
As promised, I looked into this.  mod_proxy de-chunks the incoming 
response, mod_cache caches it un-chunked, without the content-length or 
transport-encoding headers, and the content-length output filter decides 
what to do with it.  Trailers were a bit tricky since I'm not quite sure 
that I rolled them properly, but they were stripped from the response 
when apache de-chunked the proxy requests.  However, they were also 
neither cached nor even forwarded to the client.

While looking into this, I also stumbled across a paper[1]  summarizing 
some key changes between versions 1.0 and 1.1 of the protocol, which 
pointed out some useful specific examples[2] about trailers.

Based on that, it seems to me that the sensible thing to do would be to 
update the header file to include trailers after the response is 
complete (and send them as-is as trailers to the initial client).  If 
we're already doing that, then it would probably also make sense to 
calculate the entity-length to update the headers afterwards.  However, 
I'm not even sure as to where such things should be implemented, in 
mod_cache, mod_proxy(_http), or http filters, or somewhere else entirely?


View raw message