Going back to RFC 2616 section 9.2 it says "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."
So, no, OPTIONS was not just about discovering HTTP level features. It was
explicitly about discovering what the resource could do, at any and all levels.
In fact that is why we used OPTIONS to discover if the server supported WebDAV.
WebDAV is most certainly not a HTTP level feature. It's just an application
that runs on top of HTTP, just like the CouchDB API.
In practice however there are issues with using OPTIONS, see Mark's article for
a discussion of what they are.
And yes, I do mean CouchDB the API. Oddly enough I spend all day long working
with CouchDB the API and I've never run CouchDB the Erlang server. There is
this company, what was their name again? Something with a Base in it. I seem to
use their code almost exclusively. :)
I looked at the issue and it seems like a fine idea to me. I didn't vote for it
because I don't have an account on Apache's JIRA.
Thanks,
Yaron
> -----Original Message-----
> From: Jens Alfke [mailto:[email protected]]
> Sent: Thursday, February 06, 2014 7:01 AM
> To: [email protected]
> Subject: Re: Server feature detection
>
>
> On Feb 5, 2014, at 10:34 PM, Yaron Goland <[email protected]> wrote:
>
> > Honestly this sounds like a good job for OPTIONS but Mark Nottingham
> would disagree - see http://www.mnot.net/blog/2012/10/29/NO_OPTIONS.
>
> Isn't OPTIONS more about HTTP-level features? Like, what methods or
> Content-Types or Content-Encodings are accepted? I don't see it having a
> way to tell you what URLs are available, much less what options like query
> parameters or JSON content properties are allowed.
>
> > Personally I think a Couch DB specific solution (e.g. returning server data
> > as
> JSON on a GET request on the root of the server) is just fine. Good general
> purpose solutions are hard. Good specific solutions tend to be easier.
>
> Agreed :) Where I think you mean CouchDB-the-API, not specifically
> CouchDB-the-Erlang-implementation.
>
> Anyway - I've filed a ticket in Jira:
> https://issues.apache.org/jira/browse/COUCHDB-2052
>
> -Jens
