Re: Another try at OPTIONS

Scott Lawrence wrote:
>   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.
> 
Josh Cohen wrote:
    Sine PEP can do what the compliance header w/ non options method
    can do, I beleive we should leave that alone, and not define
    compliance: header behavior with non OPTIONS messages.

I believe that the text I proposed in
	http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0256.html
which says:
    A compliance header MAY appear on any message, but is
    normally used with the OPTIONS request (see section 9.2).
and which never says that a server needs to reply to a Compliance
header, except in an OPTIONS method, is the right approach.

This wording makes it clearly optional on non-OPTIONS methods;
i.e., a server doesn't even have to look for it.

On the other hand, I think it is generally a mistake to define
different behavior for a header (especially an advisory one,
such as Compliance) based on which method it is used with.
Very few of the other headers are method-specific.  (In fact,
I just noticed that Max-Forwards is currently defined so
that it cannot be used with OPTIONS; here's an example of
how such a prohibition causes trouble, since if we adopt
Josh's proposal, we need to change this.)

So I think we should at least consider how Compliance could
be used with non-OPTIONS methods, and then write the spec
for Compliance so that it's behavior is method-neutral.

This is slightly different from saying that we need to
encourage its use with non-OPTIONS methods, and I guess
I should simply remove the example of using Compliance
with a GET method, to avoid confusion.

    Additionally, excluding the goals of PEP, the reasons I can think
    of for using compliance: with a non OPTIONS method can be addressed
    by existing headers such as upgrade:...

Upgrade signals a switch between protocols.  I don't think it
overlaps much with Compliance, which is asking about what is
supported in the current protocol.  I.e., if you do OPTIONS,
then Upgrade, then OPTIONS, you would presumably get
a different Compliance response for the second OPTIONS request.
Similarly, if you do GET+Compliance, then Upgrade, then
another GET+Compliance, then you might also get a different
Compliance response on the second GET.

Also, note that "The Upgrade header field only applies to the
immediate connection.  Therefore, the upgrade keyword MUST be
supplied within a Connection header field ..."  I.e., Upgrade
is hop-by-hop (as is the HTTP/1.1 version number in the request
method line and the response status line).  But Josh has come
up with a simple and compelling design for making OPTIONS
end-to-end, and so I think Compliance also needs to be end-to-end.
That is, I don't think that Upgrade can tell a client whether
a particular option is actually supported end-to-end, but
Compliance can.

-Jeff

Received on Thursday, 24 July 1997 11:32:58 UTC