Re: [PATCH] support for Content-Encoding in wget

2004-10-25 Thread Daniel Stenberg
On Mon, 25 Oct 2004, Karsten Scheibler wrote:
The attached patch adds the option --accept-encoding-gzip to wget. If you 
enable this option the line: `Accent-Encoding: gzip' is added to the Header 
wget sends to the server. If the server responds with `Content-Encoding: 
gzip' the received data will be decompressed with gzip -d -c -.
Since wget is often built and used on systems without fork(), I believe you 
won't see it applied in this shape (assuming patches are applied at all, that 
is).

libz is the way to go, and then you could easily make it support both deflate 
and gzip.

--
 -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol


[PATCH] support for Content-Encoding in wget

2004-10-25 Thread Karsten Scheibler
Hello,

Some Webservers deliver compressed Websites if the client supports that.
This means instead of putting out the .html files directly, the files get
compressed through gzip (with Content-Encoding: gzip) before sending them to
the client.

For Apache 1.3.x there is a module available (mod_gzip) to do this (i think
Apache 2.0.x has built support for that). If a website contains much text or
html files this method will significantly reduce the traffic.

The attached patch adds the option --accept-encoding-gzip to wget. If you
enable this option the line: `Accent-Encoding: gzip' is added to the Header
wget sends to the server. If the server responds with `Content-Encoding: gzip'
the received data will be decompressed with gzip -d -c -.

Note: In my test installation Apache responds with `Content-Encoding: gzip'
also on .tar.gz-files, so an additional check is made: if the Content-Type
ends with "/x-gzip" no decompression will occur.


karsten


wget-1.9.1---1.9.1-gzip.patch.gz
Description: Binary data