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

Re: OPTIONS method

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Sun, 15 Jun 1997 18:04:40 -0700
To: Josh <josh@netscape.com>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <9706151805.aa03259@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3538
>> Not yet.  It would be a good project to come up with a complete definition
>> of OPTIONS (the existing one is only a skeleton for future extension)
>> including both the request and the response format.  I wouldn't do it
>> as a header field, though. 
>Why not?  

Because a header field is constrained by parsing limitations and
usually fails to be extensible.

>> There is a good reason why requests can
>> contain bodies, and those bodies have a type, encoding, etc.
>I dont understand the context of this sentence.
>My intent with the OPTIONS method isnt referring to a request
>per se, but a feature in the server.  Actually, feature is probably
>a bad word to use, since its being used to represent other things
>than what I think Im talking about...

I mean that you should put the feature query in the *body* of the OPTIONS
request instead of placing it in a header field.  The reason is so that
you can use the Content-Type field to indicate the query syntax, the
Content-Encoding field to encode the query (when necessary), any number
of MIC fields to provide for message integrity checks of the query, etc.
In other words, use HTTP's capacity for extensibility when it is possible
to do so.  Otherwise, we'll be stuck with a new header hack for every
conceivable communication option, and we run into difficulty differentiating
between options for future requests and options on the OPTION request.

Received on Sunday, 15 June 1997 18:09:19 UTC

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