proposal for capabilities lookup
jernst+lists.danga.com at netmesh.us
Thu Nov 17 15:14:37 PST 2005
On Nov 17, 2005, at 14:41, Dan Libby wrote:
> Has anyone considered using the existing HTTP OPTIONS method (verb)?
I certainly hadn't. This is one of these things that I was only so
peripherally aware that the periphery extended beyond the visible
> 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
> or the capabilities of a server, without implying a resource action
> or initiating a resource retrieval.
That doesn't alleviate your concern about too many round-trips,
however, does it? Maybe I misunderstand what you are saying.
> Responses to this method are not cacheable.
We don't mean this one, do we? I consider capability documents to be
eminently cacheable -- probably more so than regular content documents.
> If the OPTIONS request includes an entity-body (as indicated by the
> presence of Content-Length or Transfer-Encoding), then the media
> 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
> 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
> 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
> 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
> request on an absoluteURI for which request forwarding is
> 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
> If the Max-Forwards field-value is an integer greater than zero,
> 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.
This last part does not seem to apply.
This command seems to be more of a "tell me how smart the server is"
kind of thing than a "tell me what this resource, hosted by some
server, can do".
But thanks for bringing this up, I certainly didn't think of it. Any
other HTTP verbs that I don't know? ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051117/4cc9541f/lid.gif
-------------- next part --------------
More information about the yadis