[
https://issues.apache.org/jira/browse/COUCHDB-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061463#comment-13061463
]
Noah Slater commented on COUCHDB-1175:
--------------------------------------
I'm going to weigh in here, largely without context, to say that I am for a
solution that, by and large, respects q values as they are intended to be used.
Requiring clients to specify exactly one media type to get this working seems
quite broken to me. It assumes that clients have the ability to set this so
specifically. I am responding to Robert Newson's suggestion above, which I am
-1 on for the moment. It is worth noting that when a client lists multiple
media types with identical q values, and we able to satisfy a subset of them,
it is perfectly reasonable to then choose which we respond with based on an
internal set of preferences. That is, all things being equal in terms of client
q values, we could prefer to send text/html over application/json or whatever.
> Improve content type negotiation for couchdb JSON responses
> -----------------------------------------------------------
>
> Key: COUCHDB-1175
> URL: https://issues.apache.org/jira/browse/COUCHDB-1175
> Project: CouchDB
> Issue Type: Improvement
> Affects Versions: 1.0.2
> Reporter: Robert Newson
> Assignee: Robert Newson
> Priority: Blocker
> Fix For: 1.1.1, 1.2
>
>
> Currently we ignore qvalues when negotiation between 'application/json' and
> 'text/plain' when returning JSON responses.
> Specifically, we test directly for 'application/json' or 'text/plain' in the
> Accept header. Different branches have different bugs, though. Trunk returns
> 'application/json' if 'application/json' is present at all, even if it's less
> preferred than 'text/plain' when qvalues are accounted for.
> We should follow the standard.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
