Github user olafura commented on the pull request:
https://github.com/apache/couchdb/pull/284#issuecomment-64901623
@rnewson That thing is that the change was a non feature, it added
constraints to the pattern matching so it would pick up **q= value**, which
breaks any comparison you can make. Because browsers say they support really
anything with that value:
http://stackoverflow.com/questions/10496570/what-is-the-purpose-of-the-q-values-in-the-http-accept-request-header.
Every framework it seems at some point has someone that adds support for
those thing and everything breaks.
The reason why the initial patch didn't break badly at first is that it
only did the comparison on `text/html`, which kind of works. But then people
added it also to `application/json`, and added that first which totally broke
everything.
The intentions were good and I have a patch which is stricter about
matching it to `text/html` and `application/json` that can be merged. But
please don't try to propagate this bug to **chttp**.
If you do a web search you can find a lot of bugs caused by respecting the
q value plus wild card usage when doing comparisons. It's also an overkill, it
does not add any value, just takes it away.
The browsers say with the `Accept` header, please bring us something in
these format, but anything is also fine with us.
My test takes a real world use of the `Accept` header and most of the
versions **CouchDB** fail it which is really bad.
There are three options:
--------------------------------
* Keep the patch like it is
* Update the patch with stricter matching for the full `application/json`
and `text/html`, which is in the comments.
* Update the patch to select the quality of the matching, so to return the
one the the client prefers, this is the most correct solution and I'll make a
patch that implements this, if you choose so.
I'll also make patches for **chttp** for the two latter options if you
choose that.
http://www.django-rest-framework.org/api-guide/content-negotiation/
http://shiflett.org/blog/2011/may/the-accept-header
http://docs.openstack.org/api/openstack-network/1.0/content/Request_Response_Types.html
https://github.com/PerlDancer/Dancer2/issues/712
http://www.newmediacampaigns.com/blog/browser-rest-http-accept-headers
https://www.npmjs.org/package/contenttype //The *q-value*, if any, is
ignored.
https://pypi.python.org/pypi/negotiator/1.0.0 //possibly a better way of
doing it but I don't thing for this usecase needed
http://blog.bigbinary.com/2010/11/23/mime-type-resolution-in-rails.html
https://clojure-liberator.github.io/liberator/tutorial/conneg.html
https://docs.oracle.com/cd/E19776-01/820-4867/ghrpv/
http://mojolicio.us/perldoc/Mojolicious/Types.txt
https://parse.com/docs/js/symbols/express.Request.html
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
