[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894721#comment-13894721
]
Robert Newson commented on COUCHDB-2052:
----------------------------------------
The three examples are useful but each appears to be "what if the the
server/client doesn't implement HTTP 1.1 correctly" to me.
1) is the client sending an Upgrade header, and the server either doing the 101
switching dance or not.
2) If you send a well-formed request, with gzipped body and
Content-Encoding:gzip, the server should return a 415 rather than "barfing on
it or (worse) storing it without any indication that it's zipped."
3) That's an ugly wrinkle of couchdb, true. The multipart/related format was
added for the replicator's consumption and made that no-shuffle assumption. It
no longer does, though, and you can tell based on the published version.
There's a lot of negotiation things in HTTP itself, as indicated. There must be
examples fully outside of that?
I struggle to think of an item to go in this proposed blob that isn't a new
endpoint (e.g, Cloudant could advertise the various _search endpoints)
> Add API for discovering feature availability
> --------------------------------------------
>
> Key: COUCHDB-2052
> URL: https://issues.apache.org/jira/browse/COUCHDB-2052
> Project: CouchDB
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: HTTP Interface
> Reporter: Jens Alfke
>
> I propose adding to the response of "GET /" a property called "features" or
> "extensions" whose value is an array of strings, each string being an
> agreed-upon identifier of a specific optional feature. For example:
> {"couchdb": "welcome", "features": ["_bulk_get", "persona"]}, "vendor":
> …
> Rationale:
> Features are being added to CouchDB over time, plug-ins may add features, and
> there are compatible servers that may have nonstandard features (like
> _bulk_get). But there isn't a clear way for a client (which might be another
> server's replicator) to determine what features a server has. Currently a
> client looking at the response of a GET / has to figure out what server and
> version thereof it's talking to, and then has to consult hardcoded knowledge
> that version X of server Y supports feature Z.
> (True, you can often get away without needing to check, by assuming a feature
> exists but falling back to standard behavior if you get an error. But not all
> features may be so easy to detect — the behavior of an unaware server might
> be to ignore the feature and do the wrong thing, rather than returning an
> error — and anyway this adds extra round-trips that slow down the operation.)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
