- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 17 Jul 97 15:35:23 MDT
- To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Richard Gray writes:
> Why not OPTIONS?
>
> Using OPTIONS is a possibility, but we are still waiting for
> a formal specification for OPTIONS (everyone seems to agree
> that RFC2068 doesn't explain enough how to use it). Also,
> can you suggest a way of using OPTIONS that doesn't add round
> trips to every PUT/POST interaction?
I thought Roy explained fairly clearly that OPTIONS is meant to be
extensible. So, you invent a MIME type for the message you want to
send, and a format for the body:
http/query-authorization
METHOD=PUT
It's great that OPTIONS is extensible, but if it is going to be
used to solve a specific problem (such as the one in question),
we need to have general agreement on the syntax and semantics
for the specific extension. Your suggestion may be fine, but it's
the first time I've seen it.
True it would add round trips, but you have the same problem with the
"Expect" header, right?
No, the nice thing about Expect is that as long as the expectation
is met, there is no extra round-trip. (And if the expectation is
not met, then the client might not even want to retry the request).
It occurs to me that another workaround would be to issue HEAD against
the resource...
But, at the moment, we have no generic way of asking, with a HEAD,
whether a specific PUT (i.e., one with a specific set of request
headers) on the same resource would be accepted by the server.
(as an aside, it occured to me while looking at this, that TRACE and
OPTIONS are not listed as idempotent, but I don't see why they are not;
did I miss discussion of this somewhere?)
Actually, the whole discussion about "idempotent methods" in RFC2068
is probably wrong, and I am planning to create a new "issue" for
this (as well as a proposed solution). Mea culpa, I think I wrote
the current text.
-Jeff
Received on Thursday, 17 July 1997 15:55:07 UTC