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

Re: Another try at OPTIONS

From: Scott Lawrence <lawrence@agranat.com>
Date: Wed, 23 Jul 1997 21:46:08 -0400
Message-Id: <199707240146.VAA27015@devnix.agranat.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: "Henry Sanders (Exchange)" <henrysa@exchange.microsoft.com>, Paul Leach <paulle@microsoft.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3891

>>>>> "Henry Sanders (Exchange)" <henrysa@EXCHANGE.MICROSOFT.com>:

HS> This proposal sounds good, except for the bit about having a
HS> Compliance:  header on any request. I really dislike that part -
HS> it's just one more thing for the server to have to check for and
HS> deal with on every request. What's the rationale behind that? I'd
HS> much prefer to see it specifed as only applicable to OPTIONS.

  I agree; I'm not convinced that piggybacking the Compliance on other
  methods would be usefull.  In particular, would such a header
  provide information on what features are available for _any_ method,
  or only the one to which the Compliance header was attached?

  For the time being (that is, the next version of HTTP/1.1) I think
  that introducing Compliance (and possibly Non-Compliance) as a
  header to be used with OPTIONS is sufficient.  If we do not define
  any behaviour for it with other methods, future versions of HTTP can
  attempt to do so based on experience with the many new aspects we
  are defining.

Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/
Received on Wednesday, 23 July 1997 18:52:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC