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

Re: STATUS100 Re: Proposed resolution

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 17 Jul 97 15:35:23 MDT
Message-Id: <9707172235.AA17054@acetes.pa.dec.com>
To: HTTP Working Group <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3793
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:
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.

Received on Thursday, 17 July 1997 15:55:07 UTC

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