[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894697#comment-13894697
]
Jens Alfke commented on COUCHDB-2052:
-------------------------------------
OK, here are examples from the Couchbase Sync Gateway:
(1) WebSocket transport for the changes feed. The query param "?feed=websocket"
is recognized and triggers a change-over to the WebSocket protocol, with the
server sending a message for every change. If you send such a request to
CouchDB it will ignore the unrecognized feed type and send back a 'normal'
changes feed instead; this can trigger a lot of wasted data transfer.
(2) The body of a PUT/POST request sent to the server may be gzip-encoded
("Content-Encoding: gzip"). As far as I can tell the HTTP spec doesn't provide
any way for the client to discover whether the server supports this. If the
server doesn't, and also doesn't check the Content-Encoding request header,
it'll end up trying to read the raw data and either barfing on it or (worse)
storing it without any indication that it's zipped.
(3) When the Gateway parses an incoming document in multipart/related format,
it looks at the attachment bodies' "Content-Disposition" headers to discover
which named attachments they correspond to, instead of (as CouchDB does or used
to) assuming that they appear in the same order as the objects in the JSON
body's `_attachments` dictionary. A client might not be able to generate the
MIME bodies in exactly the same order as in the dictionary, so it might need to
check for this capability and abort the replication if it's not there, since
the alternative is getting the attachments mixed up.
> 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)
