Re: fixhrefgz - tool for converting anchors to gzipped files
On Sat, 28 Jun 1997, Christian Schwarz wrote:
>Christoph, please tell us why using "fixhrefgz" on "html.gz" files does
>not work with our web servers.
Please read the other posts.
>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
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
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.
>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
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
>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.
--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .