Re: net/http.rb, patch, possible bug, test problem

On Sat, 6 Oct 2007, Martin Duerst wrote:

> At 01:13 07/10/06, Hugh Sasse wrote:
> >On Sat, 6 Oct 2007, Tanaka Akira wrote:
> 
> >> It is confusing.  Especially if downloaded result is stored
> >> in a file which name is "foo.tar.gz".
> >
> >Agreed.  I think this must be a consequence of how Apache seems to
> >implement this facility.  Basically, a file with no extension is
> >used as a stem to search for the .gz version (etc) of the file,in
> >order to find an equivalent to send back, with "content-encoding"
> >set.
> 
> This is only one way to do it. Apache doesn't force you to do it that
> way, but in many cases, it's quite convenient.

That's the way I found out how to do it -- i.e. it seems a popular
technique...
> 
> >I think this is a bug in Apache, because if a gzipped file had
> >been requested, then that's a property of the file rather than how
> >it is encoded for transmission.
> 
> You can't use the same file as part of a negotiation (with AddEncoding)
> and independently (with AddType, as application/gzip (not registered)
> or application/x-gzip or some such).
> 
> In the former case, you say that the encoding is part of the transfer,
> and the file is just a precomputed version. Clients probably will unpack
> it. Content-Type should be taken from the uncompressed version, and I
> think Apache will automatically do that e.g. for foo.html.gz or so.
> 
> In the later case, the file is just 'something compressed' which you
> want to transfer as such. For .tar.gz, probably that makes more sense
> than using a transfer encoding.
> 
> If you have both cases on your Web site, then you have to do some
> fine-grained (per directory or per file) settings.

So you can't compress a file in transit that is already compressed?
OK, you won't get much saving, but you will get some:

brains hgs 144 %> ls -ld ruby-1.9-today.tar.gz
-rw-r--r--   1 hgs      staff    5483942 Oct  7 20:01 ruby-1.9-today.tar.gz
brains hgs 145 %> cat ruby-1.9-today.tar.gz | gzip > ruby-1.9-today.tar.gz.gz
brains hgs 146 %> ls -ld ruby-1.9-tod*
-rw-r--r--   1 hgs      staff    5483942 Oct  7 20:01 ruby-1.9-today.tar.gz
-rw-r--r--   1 hgs      staff    5473563 Oct  9 12:36 ruby-1.9-today.tar.gz.gz
brains hgs 147 %> expr 5483942 - 5473563
10379
brains hgs 148 %>

That would be more significant for a larger file over a slow link, so it
makes sense to be able to distinguish between the four cases, as you could
if they were entirely orthogonal.
> 
> >But I'm still on the learning
> >curve for this.  Are there any Apache experts out there who can tell
> >me whether I'm right, and would anyone be willing to file a bug with
> >the Apache implementors if I am?
> 
> I'm not sure I have understood the exact details of your situation,
> but up to now, it doesn't look to me like a bug in Apache. If it
> turns out to be a bug in Apache, I'll be glad to file one.
> 
> Regards,   Martin.
> 
        Hugh