couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From olafura <...@git.apache.org>
Subject [GitHub] couchdb pull request: Backport Accept check from chttpd
Date Fri, 28 Nov 2014 14:54:26 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message