proposal for capabilities lookup

[Ernst Johannes]

On Nov 17, 2005, at 14:41, Dan Libby wrote:

<snip/>

> 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  
horizon ;-)

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

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

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? ;-)


Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051117/4cc9541f/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst