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
