[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV BUG? Problem with suggested name for downloaded compressed
Re: LYNX-DEV BUG? Problem with suggested name for downloaded compressed files
Wed, 24 Sep 1997 00:41:09 +0200
> 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),
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
; To UNSUBSCRIBE: Send a mail message to address@hidden
; with "unsubscribe lynx-dev" (without the
; quotation marks) on a line by itself.