Bug#41352: HTML & dhelp
Marco Budde wrote:
> Ulf Jaenicke-Roessler wrote:
>
> > > No, HTML documentation is defined as uncompressed format.
> >
> > Hmm, I looked at the current Policy.
>
> It´s not a problem of the policy. HTML itself is defined as an
> uncompressed ascii file.
Where is it defined that way? Besides, we were not talking about
HTML itself, but about reading and storing documentation. IMO this
is a difference.
However, you are probably right, that the HTML pages shouldn't be
compressed. I already mentioned my main concern. All links would
certainly be broken or would need to be changed - quite a mess.
Obviously this prevents a lot of other problems too, although it
requires much free hard disk space. Especially for older machines
this may cause trouble.
> > This, at least, is only half-true. First, I seem to remember that some
> > version of Netscape (4.0x?) did uncompress .gz files on its own. But
>
> It´s very difficult to configure netscape to handle compression in the
> right way (gzip as MIME type and as transfer encoding). I know a lot
> of netscape installations (HP/UX, AIX) that have problems with this
> encoding.
Looks like it is very difficult to find a consistent way on different
architectures.
> > Second, like Marcus said, you can set up your web server to uncompress
> > the files.
>
> No, that´s no solution:
>
> (a) Systems like my dhelp offer the user a index of the installed html
> documentation using a www daemon *or* the local file system.
> (b) This would be to slow for a big server.
Yes. But it is possible. ;-)
BTW, what about gzipped info pages and info2www? This will also
increase your server load.
> > Finally, a relatively simple solution which could be incorporated in
> > dwww for example, is to let your Web-Server send a certain header
> > together with the gzipped page:
> >
> > Content-encoding: x-gzip
>
> This is not the job of dwww or dhelp. All better www daemons will do
> that. But this will not help, because some/a lot of browsers have
> problems with that. How should this work on a Windows client?
>
> > This works with Communicator 4.61 in Win95 (you may test it with a
> > simple cgi script).
>
> But only if you have installed gzip.
No. What makes you think this? Do you mean you need to have a gzip/gunzip
executable somewhere in the PATH? gzip isn't necessary if you access an URL
like:
http://server/~user/showgz.cgi
with showgz.cgi:
#!/bin/sh
echo Content-type: text/html
echo Content-encoding: x-gzip
echo
cat /some/gzipped/file
This does not work with Netscape Navigator 3, though. I haven't tried
Internet Explorer yet.
> > > Maybe the user don´t want to read it local?!?
> >
> > Well, it's documentation of locally installed packages. There are only
> > a few cases where it makes sense to read Linux documentation when
> > running
>
> Few cases? You´re kidding. At university I have to use such solutions
> every day. We´re taking about a server operating system!
"a few cases" means, that in general you cannot use the information you
read from your server on Win95. The packages you are reading documentation
for are supposed to work on the Debian server.
> > Win95. And you always could use Lynx in a telnet session.
>
> Lynx :)?!?
Yes. I nearly always use Lynx for reading Documentation. It's fast and
even usable in a text console. And it uses HTML the way it should be
used: HyperTextMarkupLanguage - no needless graphics, frames or imagemaps.
Ulf
Reply to: