Re: Accept-encoding: gzip
* on the Thu, Apr 26, 2007 at 02:06:57PM -0400, Roger Dingledine wrote: As a directory mirror, current requests for the mirror data cause about 2.7MB of data transfer. If the data could be delivered compressed with gzip that could significantly reduce the transfered data... Agreed. That's why we do it already. :) Search dir-spec.txt for .z. (We use zlib, not gzip, for portability reasons. But it's close enough.) Also, almost nobody fetches the v1 directory anymore (the big one you describe above). Most people (I hope) are using the v2 directory design at this point, which was introduced in Tor 0.1.1.x. Hmmm, my mistake. Thanks for the info. I tested this by simply doing a wget on the ip:port combo where my directory is. And then manually sending an Accept-Encoding header to see if it sent stuff compressed. I think I'm finally starting to get my head around the way it works now! :) Mike
Accept-encoding: gzip
As a directory mirror, current requests for the mirror data cause about 2.7MB of data transfer. If the data could be delivered compressed with gzip that could significantly reduce the transfered data... The main benefit of this being more bandwidth available for routing instead of directory transfers. This could be done in a backwards compatible fashion simply by using the http Accept-encoding: gzip option. This could even be an option that you enable/disable from the torrc. Am I right? Or am I missing something? Mike
Re: Accept-encoding: gzip
--- Mike Cardwell [EMAIL PROTECTED] wrote:
Or am I missing something?
Mike
Yes, you are missing something...and that is header
munging. If you use compression then the headers
can/may not be munged (spoofed and modified) as far as
I understand.
I do all my header munging (Firefox browser) via.
about:config and extensions, some people use Privoxy,
etc.
This is my compression setting in about:config, it
disables all compression:
network.http.accept-encoding
{gzip;q=0,deflate;q=0,compress;q=0}
Regards
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Accept-encoding: gzip
--- light zoo [EMAIL PROTECTED] wrote: --- Mike Cardwell [EMAIL PROTECTED] wrote: Or am I missing something? Mike Yes, you are missing something...and that is header munging. If you use compression then the headers can/may not be munged (spoofed and modified) as far as I understand. err...my bad. I just re-read your original email and realized your not referring to browser accept encoding. Regards, __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: Accept-encoding: gzip
On Thu, Apr 26, 2007 at 11:57:17AM +0100, Mike Cardwell wrote: As a directory mirror, current requests for the mirror data cause about 2.7MB of data transfer. If the data could be delivered compressed with gzip that could significantly reduce the transfered data... Agreed. That's why we do it already. :) Search dir-spec.txt for .z. (We use zlib, not gzip, for portability reasons. But it's close enough.) Also, almost nobody fetches the v1 directory anymore (the big one you describe above). Most people (I hope) are using the v2 directory design at this point, which was introduced in Tor 0.1.1.x. --Roger
Re: Accept-encoding: gzip
light zoo [EMAIL PROTECTED] wrote:
--- Mike Cardwell [EMAIL PROTECTED] wrote:
Or am I missing something?
Mike
Yes, you are missing something...and that is header
munging. If you use compression then the headers
can/may not be munged (spoofed and modified) as far as
I understand.
The Accept-Encoding header doesn't affect the encoding
of the headers, so there's no reason why it should make a
difference for header modifications.
I do all my header munging (Firefox browser) via.
about:config and extensions, some people use Privoxy,
etc.
This is my compression setting in about:config, it
disables all compression:
network.http.accept-encoding
{gzip;q=0,deflate;q=0,compress;q=0}
I don't think so. It certainly makes fingerprinting
your requests easier, though.
If you don't want to receive compressed content,
you should either set the Accept-Encoding
header to identity, or send no Accept-Encoding
header at all.
Have a look at section 3.5 Content Codings
in: http://ietf.org/rfc/rfc2616.txt
if you're interested in the details.
Of course if there is no reason not to accept
compressed content, it makes sense to just leave
the client's encoding settings alone.
Fabian
signature.asc
Description: PGP signature
