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

[Dick Wesseling]

address@hidden said:
> 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,
Yes.

> and then to strip the suffix implying compression from the
> > default file name for saving the results via p(rint),

I don't agree. The way I interpret the content-encoding header is that 
it indicates that an extra level of compression is applied to the 
content either by the HTTP server or by an intermediate gateway and 
that the user agent should always decompress the content. Notice that I 
am talking about *content*, not filenames. In other words, 
content-encoding ia a transport options.

For a real word example try http://www.nwsbank.nl/. When that server 
(my server) recognizes accept-encoding: gzip it attempts to compress 
the contents with gzip. This works fine when *viewing* a file with 
Lynx. When *downloading* the file Lynx always dumps the compressed data 
to disk, not what I had in mind when I did the server-side compression.

Now consider the following scenario: a Lynx user requests a .gz file. 
Now the server attempts to compress a file that is already gziped. Of 
course it is smart enough to use the original file it can't be 
compressed any further, but for the sake of the argument assume that it 
always sends the compressed contents together with a Content-encoding: 
gzip header and a Content-type: application/gzip header. After 
ungziping the content Lynx will still have a .gz file.

If my reading of the specs is correct then Content-encoding is a 
transport option only and it should be handled in a transparant way by 
the user agent. So, modifying file names based on content-encoding 
headers is not a good idea.

However, I'm not sure whether my interpretation of the specs is 
correct. Section 14.5 of draft-ietf-http-v11-spec-07 (I know, expired 
half a year ago), says:

> The Content-Encoding entity-header field is used as a modifier to
> the media-type. When present, its value indicates what additional
> content codings have been applied to the entity-body, and thus what
> decoding mechanisms MUST be applied in order to obtain the
> media-type referenced by the Content-Type header field.
> Content-Encoding is primarily used to allow a document to be
> compressed without losing the identity of its underlying media type.

This supports what I claimed above, I read: "additional content coding" 
as: "done by the server or gateway". If the underlying media type is 
applicaton/gzip then Lynx must decode to obtain application/gzip.

However, a few lines later the same document says:

> The Content-Encoding is a characteristic of the entity identified by
> the Request-URI. Typically, the entity-body is stored with this
> encoding and is only decoded before rendering or analogous usage.

This seems a contradiction. First they are talking about "additional" 
coding and next they're talking encoding being a characteristic (i.e. 
not something that is added later) of the entity. Now what am I to 
believe?

Dick


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