Re: LYNX-DEV BUG? Problem with suggested name for downloaded compressed files

[Klaus Weide]

On Mon, 22 Sep 1997, WWW server manager wrote:
[...]
> While it is reasonable to make use of Content-Encoding to uncompress a file
> for display, and then to strip the suffix implying compression from the
> default file name for saving the results via p(rint), it seems totally
> inappropriate (=wrong) for lynx to change the filename from the one in the
> URL (where that is recognisable and usable) when the file is being 
> saved unmodified (e.g. it has not been uncompressed).
> 
> Is this change to the handling of compression suffixes intentional, or a bug
> (perhaps related to the documented change in handling of filenames for
> p(rint))? It seems especially odd for it to happen in the case where lynx
> does *not* know (from HTTP headers) that the file is compressed!

Well the theory goes like this (not speaking for Fote, of course):

There are proxies that can decompress (or compress) data on the fly.
If a message is received which is not compressed (any more) according to
the HTTP headers, but the suggested filename (either from a
Content-Disposition header or derived from the URL) would indicate that it
*is* compressed, then it is assumed that it has been decompressed in this
way, so we should adapt the filename.

This does not happen (even with the fotemods code) if there is some
indication of compression other than in the filename, for example a
nonstandard "Content-Type: application/x-compress" (which would not make
Lynx actually try to uncompress the file).

> Suggesting misleading filenames in this way is potentially *very* confusing
> for users (doubly so if the text around the link did not name the file, so
> they don't know what to expect). 

The change was introduced exactly to avoid misleading filenames.
Unfortunately, it does that in some uncommon situation (conversion in
transit), while having the opposite effect in the more common situation
(where data isn't labelled correctly/sufficiently).

There is probably no way to get it always right, if HTTP headers and what
is implied by a filename (or last part of URL) contradict.  For a real
world example, try some of the http links from
<http://www.qnx.com/cgi-bin/dir_find.cgi?/usr/free/qnx4/gnu/>.

    Klaus

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