Re: OPTIONS issues from Koen

From: Roy T. Fielding (fielding@kiwi.ics.uci.edu)
Date: Thu, Mar 05 1998


To: Jeffrey Mogul <mogul@pa.dec.com>
cc: "ietf-http-ext (E-mail)" <ietf-http-ext@w3.org>
Date: Thu, 05 Mar 1998 01:12:11 -0800
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID:  <9803050113.aa29749@paris.ics.uci.edu>
Subject: Re: OPTIONS issues from Koen 

>Can someone describe a scenario where it is essential (not
>just a performance issue, but a correctness one) to be able
>to find out what options a "server" (or "proxy") supports
>with respect to a multiplicity of resources, rather than just
>with respect to a single resource (and perhaps w.r.t. a specific
>method on that resource?)

Consider an encrypted encapsulation option that allows a client
to wrap a request such that an intermediary can't see what resource
is being requested (remember WRAPPED?).  If the requestor has to identify
the intended resource just to see if that option is supported, then
it defeats the purpose of hiding the later request.

Also,

   OPTIONS * HTTP/1.1
   Host: blah

will safely probe the connection peer for its HTTP-version.
A proxy cannot forward this message, since there is no destination URI.
Likewise, having both the method and the request-target be unusual
prevents unforeseen side-effects on resources that stupidly assume
the method is what they expect in normal requests.

If we had a message body for OPTIONS, and that message body included
a query syntax specifying exactly what options we are looking for, then
it would be more useful.  No, I'm not volunteering.

.....Roy