proposal for capabilities lookup

[Dan Libby]

Sorry, I'm not yet convinced that making two requests -- the first of which 
retrieves a full HTML document -- is the way to go, when all we really want 
is the URL's capabilities, and we have additional requests to make later, eg 
OpenID. (Yes, I'm aware a HEAD request *could* be used for the first request, 
but no matching headers is found, then the consumer would need to re-request 
via GET in order to check for a pointer in the HTML, for a total of 3 
requests. )

So, I'm going to pursue another tangent here briefly.  Feel free to shoot it 
down.  :-)

On Thursday 17 November 2005 14:26, Ernst Johannes wrote:
> So I think what we've established so far is that:
>   - the capabilities lookup needs to be orthogonal to the content type

snip

> We also have the goals:
>   - we should not introduce new HTTP verbs (too messy, too hard)

Has anyone considered using the existing HTTP OPTIONS method (verb)? My 
reading of the HTTP spec indicates that it was designed for just such an 
"orthogonal" purpose.  It has also been in the spec for a long time, so 
*should* have decent support in webservers and proxies.  

Here's the relevant section of the HTTP 1/1 spec.  The first paragraph reads a 
lot like our problem description:

9.2 OPTIONS

   The OPTIONS method represents a request for information about the
   communication options available on the request/response chain
   identified by the Request-URI. This method allows the client to
   determine the options and/or requirements associated with a resource,
   or the capabilities of a server, without implying a resource action
   or initiating a resource retrieval.

   Responses to this method are not cacheable.

   If the OPTIONS request includes an entity-body (as indicated by the
   presence of Content-Length or Transfer-Encoding), then the media type
   MUST be indicated by a Content-Type field. Although this
   specification does not define any use for such a body, future
   extensions to HTTP might use the OPTIONS body to make more detailed
   queries on the server. A server that does not support such an
   extension MAY discard the request body.

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

   If the Request-URI is not an asterisk, the OPTIONS request applies
   only to the options that are available when communicating with that
   resource.

   A 200 response SHOULD include any header fields that indicate
   optional features implemented by the server and applicable to that
   resource (e.g., Allow), possibly including extensions not defined by
   this specification. The response body, if any, SHOULD also include
   information about the communication options. The format for such a
   body is not defined by this specification, but might be defined by
   future extensions to HTTP. Content negotiation MAY be used to select
   the appropriate response format. If no response body is included, the
   response MUST include a Content-Length field with a field-value of
   "0".

   The Max-Forwards request-header field MAY be used to target a
   specific proxy in the request chain. When a proxy receives an OPTIONS
   request on an absoluteURI for which request forwarding is permitted,
   the proxy MUST check for a Max-Forwards field. If the Max-Forwards
   field-value is zero ("0"), the proxy MUST NOT forward the message;
   instead, the proxy SHOULD respond with its own communication options.
   If the Max-Forwards field-value is an integer greater than zero, the
   proxy MUST decrement the field-value when it forwards the request. If
   no Max-Forwards field is present in the request, then the forwarded
   request MUST NOT include a Max-Forwards field.