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

fixhrefgz unnecessary when fixing web-browsers in the correct wayRe:

On Sat, 28 Jun 1997, Christian Schwarz wrote:

>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.

Please fix the web-browsers the same way as the web-servers. If a file
cannot be found then the web-browser simply looks for the filename with a
.gz suffix. If found it decompresses it. No problem.

>> >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 no messing around with the content of html code. If you can fix the
web-browsers then do so in the correct way (the way the web-servers work):

1. Web browser checks for file without .gz

2. If not found then web-browser checks for file with .gz and decompresses
file on the fly.

There is no need for any tool to change links in html code.

I can see that it is fun to write such a tool. Definitely. But its error
prone and not necessary.

>> 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.)


Changing the links means that a web-browser gets a .html.gz file which
could be

1. compressed html


2. decompressed html (Fascinating fascinating)

Which is it now? And how will the web-server decide if to compress or not?

I can see all kind of funny and interesting scenarios arise from this. But
they are completely unnecessary complications.

>> >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

>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.

Why would you change the links? I dont understand. If you are fixing the
web-browsers then do it in such a way that you do not need to change any

--- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ ---

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: