You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Estrade Matthieu <es...@ifrance.com> on 2002/11/14 12:37:35 UTC
mod_cache and multiple brigade
Hi,
i will quickly draw the problem i found 1 month ago:
When i am with apache + mod_proxy + mod_cache
client --> reverse_proxy_cache --> backend.
when the client ask for a document which will be handled with multiple
brigade, the first time when mod_cache is caching the document, the
client browser is able to display the document.
When the client ask again the document, mod_cache serve it from cache
and the client browser refuse to display it.
I found it was because the client browser received Content-Length header
and Transfer-Encoding=chunked header at the same time.
I put debug in mod_proxy and mod_cache, and i found:
when the backend answer the first request to multiple brigade handled
document:
backend
-
mod_proxy: content_length=size, no transfer-encoding headers and
r->chunked =0.
mod_proxy: delete content-length and Transfer-encoding headers.
http_protocol.c: ap_set_keepalive don't find CL or TE headers so:
r->chunked=0 at beginning, r->chunked =1 when ending.
http_protocol.c: ap_http_header_filter find r->chunked=1 so: add header
"Transfer-Encoding"=chunked
mod_cache: find Transfer-Encoding=chunked headers and store it in memory.
mod_cache: know the length of data he stored in memory and and the CL
header with length of data
-
client
When the backend answer the second request to multiple brigade handled
document:
rp+cache
-
mod_cache:cache_out:read_ headers: read headers from what he stored in
memory
mod_cache:cache_out: send the two headers, CL and TE
-
client: refuse to display or use document he received.
On a unique brigade handled document, the ap_set_keepalive find the
connection closed, so he don't put the r->chunked = 1 and it's working fine.
The problem is only on multiple brigade handling document
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.
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 ?
I removed the CL deleting line in the proxy_http.c code and it's now
working well, but i understand this line may be usefull, so i will
search how to resolve the problem better.
i hope you understand the problem, my english is not really good
regards,
Estrade Matthieu
__________________________________________________
Modem offert : 150,92 euros rembours�s sur le Pack eXtense de Wanadoo !
Haut d�bit � partir de 30 euros/mois : http://www.ifrance.com/_reloc/w
Re: mod_cache and multiple brigade
Posted by Brian Pane <br...@cnet.com>.
Thanks for all the diagnostic information. I'll set aside
some time to take a look at the problem this weekend if nobody
else gets to it first.
Brian
On Thu, 2002-11-14 at 03:37, Estrade Matthieu wrote:
> Hi,
>
> i will quickly draw the problem i found 1 month ago:
>
> When i am with apache + mod_proxy + mod_cache
> client --> reverse_proxy_cache --> backend.
>
> when the client ask for a document which will be handled with multiple
> brigade, the first time when mod_cache is caching the document, the
> client browser is able to display the document.
> When the client ask again the document, mod_cache serve it from cache
> and the client browser refuse to display it.
>
> I found it was because the client browser received Content-Length header
> and Transfer-Encoding=chunked header at the same time.
> I put debug in mod_proxy and mod_cache, and i found:
>
> when the backend answer the first request to multiple brigade handled
> document:
>
> backend
> -
> mod_proxy: content_length=size, no transfer-encoding headers and
> r->chunked =0.
> mod_proxy: delete content-length and Transfer-encoding headers.
> http_protocol.c: ap_set_keepalive don't find CL or TE headers so:
> r->chunked=0 at beginning, r->chunked =1 when ending.
> http_protocol.c: ap_http_header_filter find r->chunked=1 so: add header
> "Transfer-Encoding"=chunked
> mod_cache: find Transfer-Encoding=chunked headers and store it in memory.
> mod_cache: know the length of data he stored in memory and and the CL
> header with length of data
> -
> client
>
> When the backend answer the second request to multiple brigade handled
> document:
>
> rp+cache
> -
> mod_cache:cache_out:read_ headers: read headers from what he stored in
> memory
> mod_cache:cache_out: send the two headers, CL and TE
> -
> client: refuse to display or use document he received.
>
> On a unique brigade handled document, the ap_set_keepalive find the
> connection closed, so he don't put the r->chunked = 1 and it's working fine.
> The problem is only on multiple brigade handling document
>
> 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.
>
> 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 ?
> I removed the CL deleting line in the proxy_http.c code and it's now
> working well, but i understand this line may be usefull, so i will
> search how to resolve the problem better.
>
> i hope you understand the problem, my english is not really good
>
> regards,
>
> Estrade Matthieu
>
>
>
>
>
>
> __________________________________________________
> Modem offert : 150,92 euros remboursés sur le Pack eXtense de Wanadoo !
> Haut débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w
Re: Module development - Makefile
Posted by Kris Verbeeck <Kr...@ubizen.com>.
Esteban Pizzini wrote:
> I´m trying to develop a simple test module to learn how module works (I´m
> newly on this), but I have some problems defining Makefile. Is there any
> reference to do that??
What exactly are you doing in the makefile? It is probably easier to
use the 'apxs' script. Just do
apxs -c files...
--
ir. Kris Verbeeck
Development Engineer
Ubizen - Ubicenter - Philipssite 5 - 3001 Leuven - Belgium
T: +32 16 28 70 64
F: +32 16 28 70 77
Ubizen - We Secure e-business - www.ubizen.com
Module development - Makefile
Posted by Esteban Pizzini <ep...@yahoo.com.ar>.
Hi,
I´m trying to develop a simple test module to learn how module works (I´m
newly on this), but I have some problems defining Makefile. Is there any
reference to do that??
Thank You!!!
Esteban
Cobertura especial de la Copa Mundial de la FIFA Corea-Japón 2002, sólo en Yahoo! Deportes:
http://ar.sports.yahoo.com/fifaworldcup/
Re: mod_cache and multiple brigade
Posted by Graham Leggett <mi...@sharp.fm>.
Brian Pane wrote:
> 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.
+1 to the first one being a bug.
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight..."
Re: mod_cache and multiple brigade
Posted by Brian Pane <br...@cnet.com>.
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