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.) Why? Changing the links means that a web-browser gets a .html.gz file which could be 1. compressed html or 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 >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. 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 links. --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- +++ --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .