httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: mod_cache and multiple brigade
Date Sun, 17 Nov 2002 00:49:54 GMT
On Thu, 2002-11-14 at 03:37, Estrade Matthieu wrote:
[...]
> To make my mod_mem_cache work, i did this ugly patch, removing the 
> TE-header from headers stored in memory.
> It was working, but with ugly method.

That's actually a reasonable fix.  The Transfer-Encoding is a
hop-by-hop header, according to Section 13.5.1 of RFC 2616, so
we shouldn't be storing it in a cache.

> Why mod_proxy is deleting this Content-length header, i understand for 
> the TE, because the setkeepalive and http_headers_filter compute this 
> header, but why the content_lentgh is deleted ?

Yes, it seems strange that content_length is deleted.
A comment in http_protocol.c says:

         /* In order for ap_set_keepalive to work properly, we can NOT
          * have any length information stored in the output headers.
          */
         apr_table_unset(r->headers_out,"Transfer-Encoding");
         apr_table_unset(r->headers_out,"Content-Length");

But I think that comment is wrong, at least in the case of
Content-Length.  If the response has a content-length,
ap_set_keepalive will do the right thing: allow the
connection to remain open, and not try to chunk the
response.

As I see it, there are two bugs present in the code:

  * mod_proxy shouldn't remove the Content-Length.
  * mod_cache shouldn't store the Transfer-Encoding

I'm going to fix the second one now.  For the first one, I'll
wait a day or two, in case anyone knows of some good reason
why mod_proxy's removal of the C-L shouldn't be considered a
bug.

Brian



Mime
View raw message