W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: Accept-Transfer header field (was HTTP/1.1 Issues: TRAILER_FIELDS)

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Wed, 19 Nov 1997 14:49:54 -0500
Message-Id: <3.0.3.32.19971119144954.00b28100@localhost>
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>, Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
At 17:03 11/18/97 -0800, Roy T. Fielding wrote:

>In other words, I agree that there are tradeoffs, but the client has
>no input in deciding those tradeoffs (nor should it).  That doesn't
>mean the server will necessarily ignore the client's needs -- it just
>means the server will decide what is needed based on its own observation
>of the connection throughput, typical client capabilities, and the
>current resource constraint/load on the server itself.  A simple
>ordering or relative quality value given by the client says nothing
>of importance to the server, and thus provides no useful input to
>its decision.

The parameters may in fact cause the client not to be able to interpret the
response, for example in the case of using an external dictionary, or a
certain key length etc.

I think that if (not the "if") we allow parametes in the Transfer-Encoding
header field then we also need it in the accept-TE header field to allow
the client to say no thanks.

We could also say that this is for the encoding to figure out, for example
by describing the parameters in the head of the stream. Deflate already
does this to a certain extend but other filters may not.

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Received on Wednesday, 19 November 1997 11:54:52 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:03 EDT