proposal for capabilities lookup
danda at videntity.org
Thu Nov 17 14:41:32 PST 2005
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
So, I'm going to pursue another tangent here briefly. Feel free to shoot it
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
> 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:
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
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
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.
More information about the yadis