couchdb-replication mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yaron Goland <>
Subject RE: Server feature detection
Date Thu, 06 Feb 2014 16:41:28 GMT
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.



> -----Original Message-----
> From: Jens Alfke []
> Sent: Thursday, February 06, 2014 7:01 AM
> To:
> Subject: Re: Server feature detection
> On Feb 5, 2014, at 10:34 PM, Yaron Goland <> wrote:
> > Honestly this sounds like a good job for OPTIONS but Mark Nottingham
> would disagree - see
> 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:
> -Jens

View raw message