Re: new webaccel appliance
On 09/18/2007 07:40 PM, Roy T.Fielding wrote: On Sep 18, 2007, at 6:46 PM, Plüm, Rüdiger, VF-Group wrote: This works as designed. Please see the difference between the accept headers sent by IE6 and Firefox IE6: Accept-Encoding: gzip, deflate Firefox: Accept-Encoding: gzip,deflate IE6 adds an additional space between gzip and deflate. As the response varies on Accept-Encoding two representations of the response get saved (which are actually the same). It could be argued that this should not matter. Argued? The space does not change the value of the field (which is a comma-separated list). The question is really up to us as to how But this is only true for this special case of Accept-Encoding (and all other headers where the field-value is a comma separated list), correct? It wouldn't be true for a header whose field-content is made of *TEXT, right? How do we know if a field-value is just *TEXT or field-content LWS field-content? e.g. IMHO the field-value of the header Example below could be seen as *TEXT as well as token *separator token: Example: token1, token2 If we think it is *TEXT I think token1, token2 and token1,token2 are different values, whereas if we see it as token *separator token I think they represent the same value. much effort we make to compare the values for equality, since the non-match just makes our cache slow and bulky. Given the number Agreed. Depending on the answers above we may need to have a list of headers (like Accept-Encoding) where we compare the tokens in the field-value. For all other headers we would stay with the plain compare we do today. See also the TODO comments in mod_disk_cache.c::regen_key. Regards Rüdiger
Re: new webaccel appliance
On tis, 2007-09-18 at 22:41 +0200, Ruediger Pluem wrote: Agreed. Depending on the answers above we may need to have a list of headers (like Accept-Encoding) where we compare the tokens in the field-value. For all other headers we would stay with the plain compare we do today. See also the TODO comments in mod_disk_cache.c::regen_key. Or you implement If-None-Match and forget about this. Except that Apache mod_deflate is still broken and returns the wrong ETag (same as the unencoded entity).. see bug #39727.. The separator is only one of many things which makes the Vary:ing headers slightly different. You also have quality parameters, locales, etc etc. Regards Henrik signature.asc Description: This is a digitally signed message part
new webaccel appliance
Hi, I'm developing a webaccel project and I am trying to use apache to do that. I'm choosing apache because squid does not support natively http/1.1 compression. The main resources are: security (mod_security), saving bandwidth (mod_deflate) and lowering backend servers load (mod_proxy/mod_disk_cache). My testing environment is: one backend server, one webaccel server, two windows workstation (1- firefox and 1- MSIE 6.x). All steps were right (proxy, cache and deflate) but apache cached two copies of all objects for every site I access- one for firefox and one for MSIE (I checked this on headers stored in the cache directory)- When using other version of MSIE (7.x) no more copies were done. Is this a common apache (mod_cache) behaviour ? Does squid has this same content negotiation ? debian:/cache# grep 'fd.jpg?' * -r Binary file 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MOeRbRg.header matches Binary file 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK1JffA.header matches debian:/cache# cat 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MOeRbRg.header Ȥõ_:Þt:)ÍÀf: ÕÀf:http://teste.com.br:80/img/fd.jpg?Date: Tue, 18 Sep 2007 02:48:34 GMT Server: Apache Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT ETag: dd09a4-1aa-a904ef00 Accept-Ranges: bytes Content-Type: image/jpeg Via: 1.1 teste.com.br Vary: Accept-Encoding Content-Encoding: gzip Host: www.rodadaalimentos.com.br User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Accept: image/png,*/*;q=0.5 Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Referer: http://www.rodadaalimentos.com.br/estilos.css Max-Forwards: 10 Via: 1.1 teste.com.br X-Forwarded-For: 201.81.185.230 X-Forwarded-Host: www.rodadaalimentos.com.br X-Forwarded-Server: teste.com.br debian:/cache# cat 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK1JffA.header È@Ééð_:@)Át:H²µ¼f:¼¼¼f:http://teste.com.br:80/img/fd.jpg?Date: Tue, 18 Sep 2007 02:47:25 GMT Server: Apache Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT ETag: dd09a4-1aa-a904ef00 Accept-Ranges: bytes Content-Type: image/jpeg Via: 1.1 teste.com.br Vary: Accept-Encoding Content-Encoding: gzip Accept: */* Referer: http://www.rodadaalimentos.com.br/inscritos.html Accept-Language: pt-br Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: www.rodadaalimentos.com.br Max-Forwards: 10 Via: 1.1 teste.com.br X-Forwarded-For: 201.81.185.230 X-Forwarded-Host: www.rodadaalimentos.com.br X-Forwarded-Server: teste.com.br Best Regards, Fernando
AW: new webaccel appliance
-Ursprüngliche Nachricht- Von: Fernando - Dfcom Gesendet: Dienstag, 18. September 2007 16:18 An: dev@httpd.apache.org Betreff: new webaccel appliance debian:/cache# grep 'fd.jpg?' * -r Binary file 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MO eRbRg.header matches Binary file 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK 1JffA.header matches debian:/cache# cat 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/uaR/FRo/84M/RjT/oFp/MO eRbRg.header Ȥõ_:Þt:)ÍÀf: ÕÀf:http://teste.com.br:80/img/fd.jpg?Date: Tue, 18 Sep 2007 02:48:34 GMT Server: Apache Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT ETag: dd09a4-1aa-a904ef00 Accept-Ranges: bytes Content-Type: image/jpeg Via: 1.1 teste.com.br Vary: Accept-Encoding Content-Encoding: gzip Host: www.rodadaalimentos.com.br User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Accept: image/png,*/*;q=0.5 Accept-Language: pt-br,pt;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Referer: http://www.rodadaalimentos.com.br/estilos.css Max-Forwards: 10 Via: 1.1 teste.com.br X-Forwarded-For: 201.81.185.230 X-Forwarded-Host: www.rodadaalimentos.com.br X-Forwarded-Server: teste.com.br debian:/cache# cat 3IT/6la/Omd/Jn@/287/BxY4K0g.header.vary/3qK/eDq/v0G/pKc/LmQ/eK 1JffA.header È@Ééð_:@)Át:H²µ¼f:¼¼¼f:http://teste.com.br:80/img/fd.jpg?Date : Tue, 18 Sep 2007 02:47:25 GMT Server: Apache Last-Modified: Thu, 21 Jun 2007 16:01:32 GMT ETag: dd09a4-1aa-a904ef00 Accept-Ranges: bytes Content-Type: image/jpeg Via: 1.1 teste.com.br Vary: Accept-Encoding Content-Encoding: gzip Accept: */* Referer: http://www.rodadaalimentos.com.br/inscritos.html Accept-Language: pt-br Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: www.rodadaalimentos.com.br Max-Forwards: 10 Via: 1.1 teste.com.br X-Forwarded-For: 201.81.185.230 X-Forwarded-Host: www.rodadaalimentos.com.br X-Forwarded-Server: teste.com.br This works as designed. Please see the difference between the accept headers sent by IE6 and Firefox IE6: Accept-Encoding: gzip, deflate Firefox: Accept-Encoding: gzip,deflate IE6 adds an additional space between gzip and deflate. As the response varies on Accept-Encoding two representations of the response get saved (which are actually the same). It could be argued that this should not matter. Regards Rüdiger
Re: new webaccel appliance
On Sep 18, 2007, at 6:46 PM, Plüm, Rüdiger, VF-Group wrote: This works as designed. Please see the difference between the accept headers sent by IE6 and Firefox IE6: Accept-Encoding: gzip, deflate Firefox: Accept-Encoding: gzip,deflate IE6 adds an additional space between gzip and deflate. As the response varies on Accept-Encoding two representations of the response get saved (which are actually the same). It could be argued that this should not matter. Argued? The space does not change the value of the field (which is a comma-separated list). The question is really up to us as to how much effort we make to compare the values for equality, since the non-match just makes our cache slow and bulky. Given the number of those browsers, we should special-case this comparison. Roy
Re: new webaccel appliance
On tis, 2007-09-18 at 19:40 +0200, Roy T.Fielding wrote: Argued? The space does not change the value of the field (which is a comma-separated list). The question is really up to us as to how much effort we make to compare the values for equality, since the non-match just makes our cache slow and bulky. Given the number of those browsers, we should special-case this comparison. And there is also RFC2616 13.6 Caching Negotiated Responses which tells you to use If-None-Match to avoid fetching multiple copies only because of slight variations in Vary indicated request headers.. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: new webaccel appliance
I did a test here removing the Vary header from apache response. Header unset Vary I run some tests with apache all requests/responses were http/1.1 - keepalive, compression, etc And mod_cache stored just one copy of files. Firefox and MSIE 6/7 didn't show any problem. In RFC 2616 I found: An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation I don't know if removing Vary header is rfc-compliant, but resolves the problem. What do you think about? Fernando - Original Message - From: Henrik Nordstrom [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Tuesday, September 18, 2007 4:46 PM Subject: Re: new webaccel appliance
Re: new webaccel appliance
Hello, * Fernando - Dfcom [EMAIL PROTECTED] [20070918 22:06]: In RFC 2616 I found: An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation I don't know if removing Vary header is rfc-compliant, but resolves the problem. What do you think about? I think stripping the Vary header would be terribly wrong, and apache should follow RFC 2616 13.6 more thoroughly, i.e.: The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2. so, the 'special case' for matching Roy recommends to introduce is actually sanctioned by the RFC, if not even recommended/required by it. my 2 cents, Andreas -- flatline IT services - Andreas Kotes - Tailored solutions for your IT needs
Re: new webaccel appliance
Well, There is no problem to let apache do its response with Vary header. It was strange to me apache has two versions of the same object in the cache. As explained earlier this might happen because MSIE introduces a white-space after comma in the Accept-Encoding header. (maybe an apache parse mistake). Best Regards, Fernando - Original Message - From: Andreas Kotes [EMAIL PROTECTED] To: dev@httpd.apache.org Sent: Tuesday, September 18, 2007 6:56 PM Subject: Re: new webaccel appliance Hello, * Fernando - Dfcom [EMAIL PROTECTED] [20070918 22:06]: In RFC 2616 I found: An HTTP/1.1 server SHOULD include a Vary header field with any cacheable response that is subject to server-driven negotiation I don't know if removing Vary header is rfc-compliant, but resolves the problem. What do you think about? I think stripping the Vary header would be terribly wrong, and apache should follow RFC 2616 13.6 more thoroughly, i.e.: The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2. so, the 'special case' for matching Roy recommends to introduce is actually sanctioned by the RFC, if not even recommended/required by it. my 2 cents, Andreas -- flatline IT services - Andreas Kotes - Tailored solutions for your IT needs -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.487 / Virus Database: 269.13.22/1013 - Release Date: 17/9/2007 13:29
new webaccel appliance - new question
Hi, Regarding this new webaccel project (hardware appliance) I was wondering about some points: - Use Freebsd S.O - Tuning kernel and let it as small as possible. - Enable Sendfile; - Use AcceptFilter and accf_http - --enable-nonportable-atomic=yes (http://httpd.apache.org/docs/1.3/misc/perf-bsd44.html) (trying to use it in 2.2). - mod_cache, mod_proxy and mod_deflate. - filesystem tuning (inode size, async mounting ? ); - tcp/ip sysctl tuning; The main goal is not to have a portable system because we'll use a dedicated hardware, but make the system as fast as possible. I'm searching for another points to optimize freebsd, tcp/ip stack and apache. There are some discussions about window_scaling, tcp buffers, etc. What do you think about? Best Regards, Fernando
