lynx-dev
[Top][All Lists]
Advanced

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

Re: LYNX-DEV Re: Accept-Encoding: gzip, compress


From: Klaus Weide
Subject: Re: LYNX-DEV Re: Accept-Encoding: gzip, compress
Date: Mon, 24 Mar 1997 09:28:34 -0600 (CST)

On Sun, 23 Mar 1997, Hynek Med wrote:
> On Sat, 22 Mar 1997, Klaus Weide wrote:
> 
> Then - do you think it's a good idea to use gzip/compress compresssion and
> Content-encoding header in output of cgi-scripts (provided the browser
> sent propper Accept-Encoding header)?  

If you can afford the overhead and get it right, yes.  You could also
try to detect Netscape-for-Unix from the User-Agent header, but that's
not recommended.  Also the script should explicitly set Last-Modified
(or Expires and/or "Cache-Control: max-age=...") headers so that the
output can be cached.

> I haven't seen any browser other
> than lynx sending Accept-Encoding headers, and even Netscape for Unix
> understands gzipped documents as good as lynx.. I think of this mainly for
> our "nationalization" cgi scripts recoding the diacritics. I would make
> the load on the machines a bit higher, but it would save some bandwidth..

Keep in mind that it wouldn't do much for loading time if the slowest
link in the network path between client (Lynx) and server is a modem
connection (which most likely already uses some kind of compression).

> Of course, there would be a problem with systems where gzip is missing or
> where the path to compress/gzip isn't correct - perhaps lynx should check
> if gzip/compreses executables exist in the places it expects - surely
> during the autoconfigure, and maybe even after starting lynx - if gzip is
> missing, lynx shouldn't send that it accepts gzip-encoded documents.. (And

Currently Lynx always sends the Accept-Encoding header because it
assumes that gzip and uncompress are always available.  (In other
words, GZIP_PATH and UNCOMPRESS_PATH are assumed to always be defined
and point to the correct place.)  Maybe you can get Tom to add yet
another test..

> it often happens when someone picks a pre-compiled lynx for, say, HP-UX,
> gzip is likely to be on the machine lynx was compiled but may be missing
> on the machine it's run.. Even on my Linux at home gzip was in /bin but
> lynx thought it to be in /usr/bin..)

Here is a suggestion for people who make precompiled binaries
available to others:  Change the definitions for the aux programs in
userdefs.h so they don't include a directory path.  Of course this
will require that those programs can then be found in the user's PATH
when Lynx is run.

There are good reasons for having the aux programs' paths hardwired in
userdefs.h, but the people for whom that is important would not (and
should not) install a precompiled lynx anyway.  (I assume that would
be mostly multi-user installations.)

I don't know how this applies to the Win/DOS Lynx - if gzip is not
available there, then Lynx probably should not be sending
Accept-Encoding in HTTP.c.  (It wouldn't be absolutely wrong since
Lynx can still accept a compressed file for downloading.)

   Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]