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

>>>>> "JM" == Jeffrey Mogul <mogul@pa.dec.com> writes:

JM> Koen writes:
JM>     And no gunky parameters about compression quality or dictionaries
JM>     please -- adding these would take the whole thing way beyond a 1.1
JM>     cleanup, and how are we ever going to claim two independent
JM>     implementations for such things if we add them?

JM> [...]

JM> But beyond that, if we don't add parameters NOW, we will never
JM> be able to do so, because then there will be an incompatibility
JM> with the installed base.  History has shown us that HTTP has
JM> suffered in many ways from a lack of extensibility mechanisms,
JM> and since this one is exactly the same as we already have used
JM> in other headers, it seems rational to use it for transfer-codings.

  I buy the argument that allowing for extentions in the syntax is a
  good thing even (perhaps especially) if we don't use them now, so
  put it in.

  I also feel strongly that the transfer coding is the servers
  business and 'q' values will, in practice, be ignored.  If this
  argues for renaming the header to not be Accept-*, then rename it.

--
Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Wednesday, 19 November 1997 15:39:37 UTC