[
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894905#comment-13894905
]
Benoit Chesneau commented on COUCHDB-2052:
------------------------------------------
{quote}Well, CouchDB doesn't implement HTTP 1.1 correctly then...{quote}
Some parts are not well supported yes... But that could be fixed :)
{quote}
(1) I tried sending a GET request for the changes feed with an Upgrade header
and "feed=websocket"; it ignored the header and sent back the entire changes
feed in normal format.{quote}
Yeah we should return a 501 error probably.
{quote}
(2) I tried sending it a gzip-encoded PUT request body, and it failed with a
400 status with message "invalid_json". Apparently it ignored the
Content-Encoding header. (I'm still on version 1.4, though.){quote}
On which entry point?
{quote}
(3) You're right that one could check the version, but part of the reason for
this proposal was to avoid having to have hardcoded knowledge of versions. It's
not just one version check either – IrisCouch and Cloudant (and BigCouch?) have
independent version numbers, so you'd have to know what versions they
incorporated the fix into.{quote}
This is why I propose to have the supported link. But it may not be enough.
What I still understand is how you feature proposal fit the
bill. I mean there should be a common place where to define these
capabilities/features then. At least to know which one to pick, and
which one to advertise. Any idea on how you would like to see it?
> 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)
