gzip compression

This is a repost, I sent that from a wrong email address and just found 
that it never get into the list.


Hello, I reported about oddities in the gzip handling some time ago, I
still see the issues, and as I still haven't time to dig into this I
report it again in order to see if someone has run into the same problem
and found the (I think so) easy patch.

The problem is about enabling compresion in tux, some practical case here:
-rw-r--r--    1 root     root         9531 sep 12 20:38 index.html
-rw-r--r--    1 root     root         3094 sep 12 20:39 index.html.gz

You see, index.html.gz is newer and smaller than index.html, so tux
server it, that's correct, the problem comes from this:

[coma@quartz ~]$ wget -Y off -S --header "Accept-Encoding: gzip,
deflate, compress;q=0.9" http://head.redvip.net/
--20:39:19--  http://head.redvip.net/
            => `index.html'
Resolviendo head.redvip.net... hecho.
Conectando con head.redvip.net[192.168.0.20]:80... conectado.
Petición HTTP enviada, esperando respuesta...
  1 HTTP/1.1 200 OK
  2 Content-Type: text/html
  3 Connection: Keep-Alive
  4 Date: Thu, 12 Sep 2002 18:39:18 GMT
  5 Content-Encoding: gzip
  6 Server: TUX/2.0 (Linux)
  7 Content-Length: 9531
  8 ETag: "9531-dnianpbf"
  9 Accept-Ranges: bytes
10 Last-Modified: Thu, 12 Sep 2002 18:38:13 GMT

32% [===========>                         ] 3,094          2.95M/s
ETA 00:00

20:41:19 (2.95 MB/s) - Conexión cerrada en el byte 3094. Reintentando.

--20:41:20--  http://head.redvip.net/
   (intento: 2) => `index.html'
Conectando con head.redvip.net[192.168.0.20]:80... conectado.
Petición HTTP enviada, esperando respuesta...
  1 HTTP/1.1 206 Partial Content
  2 Content-Type: text/html
  3 Connection: Keep-Alive
  4 Date: Thu, 12 Sep 2002 18:41:19 GMT
  5 Server: TUX/2.0 (Linux)
  6 Content-Length: 6437
  7 ETag: "9531-dnianpbf"
  8 Accept-Ranges: bytes
  9 Last-Modified: Thu, 12 Sep 2002 18:38:13 GMT
10 Content-Range: bytes 3094-9530/9531

100%[====================================>] 9,531          6.14M/s
ETA 00:00

20:41:20 (6.14 MB/s) - `index.html' guardado [9531/9531]

So you see, Tux closes the connection at byte 3094, *exactly* the size
of the gzip file, and in fact the first 3094 bytes are the index.html.gz
gzip file, but the second attemp are the 6437 last bytes of index.html,
it's strange.

The simptoms are that wget takes a unusual long time until tux times
out, and mozilla has the same problem.

I think that the solution is to send the content length and ETag of the
index.html.gz file instead of the asked one. It should be easy, but I'm
very tight in time.

If some one takes over it I would be very willing to test it, because
I'm in a 256/128 ADSL, so I need it, BTW Apache 1.3.x & 2.0.x does it rigth.

Regards.

-- 
Jorge Nerin
<[email protected]>