httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: Content-encoding, gzip, and all that stuff (fwd)
Date Thu, 30 Apr 1998 01:27:04 GMT
You know, mod_negotiation seems really lame in some cases. 

I have foo.html, and foo.html.gz.  foo.html.gz is smaller than foo.html. 

I request /foo, without any Accept-Encoding, and it sends foo.html. 
That's cool, that's right. 

I request /foo, with "Accept-Encoding: gzip", and it sends foo.html. 
That's not cool, that's broken.

The users below are a little confused, I think they're requesting
foo.html, and in any event that should return foo.html.

It wouldn't be a bad idea for mod_negotiation to go through a little
updating... like clean out the algorithms which are from early draft
standards, and update them with whatever is in HTTP/1.1. 


---------- Forwarded message ----------
Resent-Date: Wed, 29 Apr 1998 18:07:44 -0700 (PDT)
Path: not-for-mail
From: Eric Bina <>
Newsgroups: netscape.public.mozilla.general, netscape.public.mozilla.general
Subject: Re: Content-encoding, gzip, and all that stuff
Date: Wed, 29 Apr 1998 18:07:40 -0700
Organization: Netscape Communications
Lines: 75

Glynn Clements wrote:
> Eric Bina wrote:
> > What I would love to see working now would be if a server had both
> > foo.html and foo.html.gz and you asked for foo.html with an
> > Accept-encoding of gzip, the server should send you foo.html.gz with
> > a mime type of text/html and content-encoding gzip.
> Accept-Encoding != Preferred-Encoding

We have no Preferred-Encoding in http1.1.  I need to work with what
we have.

> If the connection between the client and the server is fast (e.g.
> intranet), then gzipping the file is probably just going to slow
> things down.
> In order to work effectively, you would need to be able to configure
> one end or the other to conditionally compress the data as
> appropriate.

The http1.1 spec tries to allow this with quality values assigned
to the Accept-Encoding.  So if the client was smart enough to know
it was on an intranet all the way from client to server, it could
adjust the Accept-Encoding accordingly.

> > This doesn't happen right now, because Apache insists on sending
> > foo.html if it exists.
> Which is probably the right thing to do, unless you've specifically
> told it otherwise. Maybe foo.html is the index page of a multi-page
> document, whereas foo.html.gz is the whole document as a single file
> (e.g. the `for printing' version).

No, I don't think Apache would ever understand that.  With Multiviews
turned on it definitly assumes foo.html and foo.html.gz are the
same content with the later just being a compressed version of the
former.  Given those assumptions it isn't doing the right thing.

> IIRC, neither the HTTP nor the URL specifications impose these kinds
> of relationships amongst URLs.

Sorry, I wasn't trying to imply a relationship among URLs.  Just assume
that the server has two items where it knows that one is the compressed
version of the other.  It can choose to serve either, if I request
a URL that maps to the uncompressed item and say I want to accept
gzipped content, I want it to serve me the compressed version.

> > Apart from fixing that we have the issue of what to do if you clicked
> > on a link for foo.html.gz.  If the link was clicked  in normal browsing
> > then your browser will send an Accept-encoding of gzip.  So, should
> > the server send foo.html.gz as mime text/html and content-encoding
> > gzip, or should it send it as mime application/gzip with no
> > content encoding?
> The former provides more information than the latter. The client can
> always map the former to the latter, discarding the actual content
> type. It can't reverse the transformation.

True, but if the server sends it as content-encoded gzip that implies
the client should unzip it.  If the file had been something like
foo.tar.gz many people would argue that serving that as mime
application/tar content-encoding gzip is wrong becuase then the
browser would uncompress it and present the user with a application/tar
file to save or send to another application.


View raw message