[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fixhrefgz - tool for converting anchors to gzipped files



On Sat, 28 Jun 1997, Christoph Lameter wrote:

> On Sat, 28 Jun 1997, Christian Schwarz wrote:
> 
> >
> >Hi!
> >
> >Christoph, please tell us why using "fixhrefgz" on "html.gz" files does
> >not work with our web servers.
> 
> Please read the other posts.

Please answer my questions! I haven't found an answer elsewhere.

> >As far as I have understood, these web servers are so intelligent that if
> >a file "foo.html" is referenced, but only "foo.html.gz" is found, they
> >uncompress the file on-the-fly and pass the decompressed version to the
> >web browser.
> 
> Exactly. So there is no problem when using web-servers.
> 
> >However, as you surely know, this does not work without web server, since
> >the browsers are not looking for "foo.html.gz" if "foo.html" is
> >referenced.
> 
> Yes. But if you change the references then the web-serverws will no longer
> do on the fly decompression. They will serve the links as .gz which is not
> universally supported by web-browsers not under Debians control.

But most of the web browser can easily be fixed. Since "boa" is really
very small and already supports on-the-fly decompression, we can include
it even in the base system so everyone out there his it installed. It can
be started on another port than 80, I think, so it doesn't conflict with
other web servers.

> >Thus, we are considering changing the "href's" to "foo.html.gz" and fix
> >the browsers, where possible, to uncompress the file on-the-fly. If the
> >browser cannot be fixed (for example, if we don't have the source code) we
> >could probably offer a simple web server (e.g. boa) to do this
> >automatically.
> 
> Please think about this.
> 
> You are proposing that a web-server is supposed to be searching through
> the .html code it serves and replace all links referring to .html.gz by
> .html links?

No. The links are adopted from ".html" to ".html.gz" where necessary by
the _maintainer_ when the ".deb" is created. We have a Perl tool to do
this. (I posted it here, yesterday.)

> >But why can't "boa" be extended to uncompress "foo.html.gz" on-the-fly
> >when _this_ file is requested, just as "foo.html" would have been
> >requested and that file does not exist?
> 
> It can certainly do this but the links are the problem!!!!
> 
> It will still serve the .html file (now uncompressed) containing .html.gz
> links which are not understood by web-servers outside of the Debian realm.

Why? The files are called ".html.gz" in the file system. Thus, these links
are valid. We only have to implement on-the-fly decompression on some web
servers. (This functionality could be useful for others, too, so we could
forward our patches to the upstream maintainers of the web servers as
well.)

Christoph, I take your objection seriously, I don't want to include
"technical nonsense" in our policy manual. So please explain to us what
difficulties you see.


Thanks,

Chris

--                  Christian Schwarz
                   schwarz@monet.m.isar.de, schwarz@schwarz-online.com
                  schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
                       
                PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
              
 CS Software goes online! Visit our new home page at
 	                                     http://www.schwarz-online.com


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: