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

[Klaus Weide]

On Sat, 22 Mar 1997, Foteos Macrides wrote:

> Hynek Med <address@hidden> wrote:
> >If I understand it right, lynx can negotiate sending compressed data with
> >the http server. Does anybody know of a server which supports this, so I
> >can try it? 

[These comments in addition to what Fote wrote]
Lynx has been sending "Accept-Encoding: gzip, compress" or (earlier)
"Accept-Encoding: x-gzip, x-compress" headers to all HTTP servers for a
long time, so in a sense you *have* been testing this.  Of course (as Fote
points out) this is not really negotiation. 

>       The conneg draft is still just a draft being regularly revised,
> not an RFC.  Lynx does not support negotiation in the full sense of the
> most current draft.   For Content-Type negotiation, Lynx indicates its
> preferences based on the presentation mappings, and will render and
> display the body of a 300 reply status if none of the preferences can
> be met by the server.  That body should include descriptions and links
> for what is available from the server.
> 
>       For Content-Encoding, Lynx simply indicates a preference for
> a gzipped or Unix compressed transmission if available.  I would guess
> the Apache server supports this type of negotiation, but I don't know

This article has a description of negotiation in Apache:
  <URL: http://www.apacheweek.com/features/negotiation>
According to that text, (pre conneg-draft style) negotiation on
Content-Type should work in Apache as for other dimensions (media type,
language, etc.)

> a URL for one which uses it according to the conneg draft.  Many
> servers are set up to handle files with names of the form foo.blah.gz
> by sending a Content-Encoding with value x-gzip, and a Content-Type
> based on the server's mapping for ".blah", but that's not true
> negotiation, i.e, it will occur regardless of whether the browser sent
> an Accept-Encoding header.
> 
>       Klaus has been active in the development of the conneg draft,
(to the extent of reading the drafts and commenting on the http-wg list)

> and I'm sure could implement true negotiation when the time is right
> for doing it fully.

Koen Holtmann's drafts about Transparent Content Negotiation deal with the
other dimensions, but leave Content-Encoding out of the scheme.  It's
somewhat different than the other dimensions: a client either does
implement e.g. gzip decoding or it doesn't, and it doesn't make as much
sense to control this via user preference settings (except for testing).

As long as the popular browsers on MS platforms don't support "gzip" and
"compress" decoding (and I doubt they ever will) there isn't much
incentive for Web sites to support it.  The coming thing seems to be a new
"Content-Encoding: deflate"  (see references in RFC 2068).  
A new version of the W3C's libwww was just released yesterday.[*]  The
changes from the previous version 5.0A (except for bugfixes) are
summarized as follows on
<URL: http://www.w3.org/pub/WWW/Library/User/ReleaseNotes.html>:
 
 New Features and APIs

     * Added support  pipelining
     * Support for zlib based decompression in content encoding
 
("zlib" is the format used by the "deflate" compression mechanism.)


[*] I also read on the W3C site
   This is expected to be the last release of Libwww, since we are now
   moving to the Jigsaw code base, written in Java.

Hmm...

   Klaus

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