Subject: OPTIONS *

From: "Julian Reschke" <[email-masked]>
Date: Mon, 24 Nov 2003 22:08:38 +0100

Hi,

I'd like to see a clarification about what clients can expect upon OPTIONS
*. In particular, can they expect to find out about *any* method name
supported on that server? I'm asking because this doesn't seem to be the
case for at least two major server bases, being:

- Apache (for instance, additional method names supported by mod_dav aren't
listed) and
- generic Java servlet engines (servlet API does not support delegation of
requests against "*" to all installed web applications).

Regards, Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 24 Nov 2003 14:33:24 -0700 (MST)

On Mon, 24 Nov 2003, Julian Reschke wrote:

> I'd like to see a clarification about what clients can expect upon
> OPTIONS *. In particular, can they expect to find out about *any*
> method name supported on that server?

Support for OPTIONS is optional so client should not rely on that
mechanism exclusively. That is, they should expect "405 Method Not
Allowed" or "501 Not Implemented" response, among other things.

Even if OPTIONS method is supported, client cannot expect a list of
supported optional method names in response to OPTIONS * (in general)
because supported optional methods may depend on the request URI. Here
is a quote from RFC 2616, it may also clarify why Java API does not
propagate * requests:

   If the Request-URI is an asterisk ("*"), the OPTIONS request is
   intended to apply to the server in general rather than to a
   specific resource. Since a server's communication options typically
   depend on the resource, the "*" request is only useful as a "ping"
   or "no-op" type of method; it does nothing beyond allowing the
   client to test the capabilities of the server. For example, this
   can be used to test a proxy for HTTP/1.1 compliance (or lack
   thereof).
   ...
   A 200 response SHOULD include any header fields that indicate
   optional features implemented by the server and applicable to that
   resource

HTH,

Alex.

P.S. The "can be used to test a proxy for HTTP/1.1 compliance" phrase
     above probably meant to say "can be used to detect HTTP version
     of a proxy" since one cannot really test for compliance using an
     optional method.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 24 Nov 2003 23:26:37 +0100

> Allowed" or "501 Not Implemented" response, among other things.

OK, that's clear. I was thinking about the case where OPTIONS is 
supported and implemented...

>    specific resource. Since a server's communication options typically

I think it would be nice if the spec would clarify what "supported in 
general" means... Specifically for the "Allow" header: does it mean

- the methods listed in the Allow header are supported by all resources?
- methods not listed in the Allow header aren't supported by any resource?
- something else...?

>      of a proxy" since one cannot really test for compliance using an

To me it seems that "OPTIONS *" is effectively useless except for the 
thing above -- testing compliance to a specific HTTP version. I think a 
spec revision should just state that.

Julian

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 24 Nov 2003 15:58:59 -0700 (MST)

On Mon, 24 Nov 2003, Julian Reschke wrote:

> I think it would be nice if the spec would clarify what "supported
> in general" means... Specifically for the "Allow" header: does it
> mean
>

While "supported by all resources" sounds logical, I suspect the true
intent was to use "*" for things that are not resource-dependent at
all (e.g., server ability to server N concurrent clients or switch to
non-TCP transport). In other words, there should not be any Allow
header returned for OPTIONS *.

I doubt it is possible to formally define what * is referring to
because HTTP does not have a definition of a "server" that is suitable
for this context. Such a definition would be outside of the
communication protocol scope. Essentially, the definition of "*" or
"server" in this context is implementation/environment dependent.

> To me it seems that "OPTIONS *" is effectively useless

It is potentially useful for announcing support for custom server
features _not_ documented in RFC 2616. The documentation for such a
feature would define exactly what to include in or expect from an
"OPTIONS *" response. I bet somebody out there is using it for such
custom purposes.

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 09:28:27 +0100

> header returned for OPTIONS *.

That would be my interpretation as well, but I think the wording of 
RFC2616 is really too vague here.

> "server" in this context is implementation/environment dependent.

Yes.

> "OPTIONS *" response. I bet somebody out there is using it for such

Well, that's what got us here (WebDAV using it for that). However the 
issue here is that the "OPTIONS *" request in reality get's never passed 
to the various 'modules' inside a server that would need to be able to 
respond it (for instance neither Apache/mod_dav nor Tomcat/Webdav 
servlet set the special "DAV:" response header defined for OPTIONS in 
RFC2518).

Any chance to get that onto the RFC2616 issues list?

Regards, Julian

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 25 Nov 2003 09:10:27 -0700 (MST)

On Tue, 25 Nov 2003, Julian Reschke wrote:

> the issue here is that the "OPTIONS *" request in reality get's
> never passed to the various 'modules' inside a server that would
> need to be able to respond it (for instance neither Apache/mod_dav
> nor Tomcat/Webdav servlet set the special "DAV:" response header
> defined for OPTIONS in RFC2518).
>

In my experience, you need to convince one of the original authors or
anybody Scott Lawrence trusts that a certain change is warranted. If
you succeed, the change will be posted to
http://purl.org/NET/http-errata with a link to the discussion on the
list.

The change does not have to be an "errata" or "issue" with the
protocol itself.

Your best bet is probably to post a specific wording to this list and
wait for a reaction.

Alex.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 17:20:35 +0100

> Your best bet is probably to post a specific wording to this list and

OK, that sounds reasonable. Maybe we can come up with a good replacement 
text.

Julian

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 25 Nov 2003 08:36:26 -0800

Alex Rousskov <[email-masked]> wrote

    
    In my experience, you need to convince one of the original authors or
    anybody Scott Lawrence trusts that a certain change is warranted.

I think there is no doubt that many or most of the authors think
that OPTIONS is basically broken in RFC2616, so a well-designed
rewording is probably welcome.  However, given that (1) we are
not likely to change the version number at this stage, and (2)
without changing the version number we cannot really expect
to place new requirements on servers, any change that might be
proposed is probably more likely to be of the form "clients
cannot count on OPTIONS behavior, but here's some advice to server
implementors."

-Jeff

P.S.: for what it is worth (not much at this point), Scott
himself was a co-author of draft-ietf-http-options-02.txt,
"Specification of HTTP/1.1 OPTIONS messages", back in 1997.  My
recollection is that the Working Group rejected this approach and
so the I-D died, but in my opinion it was the best design that was
available.  (My opinion is biased, for reasons that might be
obvious to anyone who reads this draft, available via Google and
other fine search engines.)

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 25 Nov 2003 10:26:45 -0700 (MST)

Given Jeff's comments, would it make any sense for those who need a
working OPTIONS to specify their own extension method (e.g., FEATURES)
and publish a small RFC instead of patching RFC 2616?
Draft-ietf-http-options could be a starting point. One problem would
be with proxies that do not pass extension methods on, unfortunately.
But some do not pass OPTIONS as well, so it is not such a "new"
limitation.

Adding some extension header to OPTIONS, to signal new well-defined
functionality would be a similar approach that does not require an
extension method.

Alex.

On Tue, 25 Nov 2003, Jeffrey Mogul wrote:

> rewording is probably welcome.  However, given that (1) we are not
> likely to change the version number at this stage, and (2) without
> changing the version number we cannot really expect to place new
> requirements on servers, any change that might be proposed is
> probably more likely to be of the form "clients cannot count on
> OPTIONS behavior, but here's some advice to server implementors."
>
> -Jeff
>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 19:22:13 +0100

> and publish a small RFC instead of patching RFC 2616?

Possibly, but I don't think this applies to the questions that got us here.

WebDAV uses the DAV: response header in OPTIONS, and so far this seems 
to work just fine. The only disagreement that we have (had?) is whether 
clients can rely on "OPTIONS *" returning something meaningful. I think 
it has been shown that they can't, thus RFC2518bis shouldn't add any new 
language suggesting that. In addition, we have no evidence of clients 
that actually use that.

Regarding Lisa's draft for a PATCH method, I still believe that getting 
rid of any dependencies on OPTIONS will make it easier to be 
acccepted/implemented. At the very least it shouldn't require "OPTIONS 
*" to do anything it won't actually do in practice.

> functionality would be a similar approach that does not require an

That's what WebDAV already does 
(<http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_DAV>), and 
besides the problem with "OPTIONS *", there doesn't seem to be any 
real-world problem with it.

Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 25 Nov 2003 19:29:58 +0100

Scott Lawrence wrote:

 > ...
> I agree that the best that can be done now is to document what can and
> cannot be achieved with what we have (pretty limited, but it does make
> a good no-op message; we used it that way in RFC 2817).

Agreed. So I think what we want to replace is 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.2.p.4>:

"If the Request-URI is an asterisk ("*"), the OPTIONS request is 
intended to apply to the server in general rather than to a specific 
resource. Since a server's communication options typically depend on the 
resource, the "*" request is only useful as a "ping" or "no-op" type of 
method; it does nothing beyond allowing the client to test the 
capabilities of the server. For example, this can be used to test a 
proxy for HTTP/1.1 compliance (or lack thereof)."

Any proposals for replacement text?

Julian

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 25 Nov 2003 12:50:27 -0500 (EST)

> The change does not have to be an "errata" or "issue" with the

But it helps...

> Your best bet is probably to post a specific wording to this list and

Specific text is essential - I'd suggest some form of exactly what
text you would replace with exactly what it should become, because
it's the only way to get it reviewed.  Don't wait long - to quote from
the errata page:

   New drafts of [RFCs 2616 & 2617] are being prepared now,
   incorporating all of the following corrections, in preparation for
   requesting that they be advanced to full Standard status. If you
   have an issue with any of these resolutions, or if you think that
   you've found another, you should post it to the HTTP Working Group
   list and get the issue discussed there as soon as possible.

-- 
Scott Lawrence        
  http://skrb.org/scott/

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 25 Nov 2003 13:08:47 -0500 (EST)

Jeffrey Mogul <[email-masked]> writes:

> available.

My recollection would be more like the working group had gotten too
tired at that point to do the work and too worried about adding
anything to the spec that wasn't already in deployed software (an
unavoidable consequence of a long specification process for an
already-popular protocol).

For those who are curious, HTTPs cousin SIP actually ended up using
OPTIONS and specifying what it was good for:

  http://www.apps.ietf.org/rfc/rfc3261.html#sec-11.1

-- 
Scott Lawrence        
  http://skrb.org/scott/

---

From: Jim Gettys <[email-masked]>
Date: Tue, 25 Nov 2003 14:09:13 -0500 (EST)

>    list and get the issue discussed there as soon as possible.

Yes, like I've done 90% of the work on a new draft, and was expecting
to/expect to issue a draft this week.

Text and discussion should be *now*.

                             Thanks,
					- Jim

-- 
Jim Gettys <[email-masked]>
HP Labs, Cambridge Research Laboratory