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

[WWW server manager]

Using lynx 2.7.1 + fotemods.zip dated 21 Sep 1997, on Sun Solaris 2.5.1
(SPARC) with Sun's C compiler ...

Fetching compressed tar files (xxx.tar.Z) from web servers (i.e. HTTP not 
FTP) by selecting the relevant links explicitly using the d(ownload) command
in lynx seems to behave oddly, and certainly differently from older versions
of lynx (though I don't know when it changed).

Where there is a well-defined filename available from the URL, I would 
expect lynx to offer that as the default for saving downloaded files (and
that's what happened with the older versions I've used), but with the
version described above it sometimes omits the compression suffix (for .Z, I
presume .gz would be treated similarly), although the file *is* saved in
in its original form. With e.g. lynx 2.4.1, the name from the URL is used
unaltered.

Limited testing suggests that .Z (presumably also .gz, but I wasn't able to 
test that) is dropped when the server does not send a Content-Encoding
header, and retains .Z (and .gz) if the encoding is specified by the server,
though in all cases the file was saved in its original form, with no change
to the encoding (thus making the proposed filename misleading when .Z was 
dropped). In the cases I examined, the files (xxx.tar.Z and xxx.tar.gz) were
all served with Content-Type application/octet-stream.

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!

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). I was hoping to upgrade lynx before the
imminent start of term (not least to fix the security issues, so it has to be 
2.7.1 + subsequent updates), but that may not be an option unless this problem
can be fixed.

                                John Line
-- 
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to address@hidden
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;