Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#32 closed editorial (wontfix)

OPTIONS *

Reported by: mnot@… Owned by:
Priority: Milestone: unassigned
Component: p2-semantics Severity:
Keywords: Cc:

Description

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)

Change History (3)

comment:1 Changed 12 years ago by mnot@…

  • Component set to semantics
  • Milestone set to unassigned
  • version set to d00

comment:2 follow-up: Changed 12 years ago by fielding@…

  • Resolution set to wontfix
  • Status changed from new to closed
  • Type changed from design to editorial

The answer is "no" to both expectations. This is very clear already:

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).

I don't see any point in listing all the possible things that can't be determined at the server-level; it is implementation-dependent.

comment:3 in reply to: ↑ 2 Changed 12 years ago by julian.reschke@…

Replying to fielding@gbiv.com:

The answer is "no" to both expectations. This is very clear already:

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).

I don't see any point in listing all the possible things that can't be determined at the server-level; it is implementation-dependent.

I have to disagree. This question comes up again and again, so it seems the specification is not sufficiently clear.

Note: See TracTickets for help on using tickets.