couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-431) cors - aka Cross-Origin Resource Sharing support
Date Wed, 28 Nov 2012 21:42:00 GMT


Benoit Chesneau commented on COUCHDB-431:

1. I am not sure it' s needed as well. Though I noticed (it should requires real benchmarking)
that using vhost + cors + rewrites introduced some delays on a busy node. To solve that I
would like to introduce the notion of middleware. 

A middleware would take a request and possibly return it with new properties or just as is.
It would also have the possibility to stop the request.

 The point here is to reuse the code between vhost the rewriter and the cors thing so we will
be faster and cleaner (by caching some properties and other things like skipping the recreation
of Mochireq or removing some ugly thing we do with headers during rewriting behind a vhost).
It could possibly be used for auth and routing too. 

I have some test code around but nothing to show yet. I do think that we shouldn't release
without that change.

2. I have some questions on some naming also the way the headers are applied. I will elaborate
further on that patch later this week.

3. Will provide that, 

4. Which tests are missing for you ? Do you want to test all cases ? Maybe we could simplify
the test by passing different headers and expected response as a list. 

> cors - aka Cross-Origin Resource Sharing  support
> -------------------------------------------------
>                 Key: COUCHDB-431
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: HTTP Interface
>    Affects Versions: 0.9
>            Reporter: James Burke
>            Assignee: Benoit Chesneau
>            Priority: Blocker
>         Attachments: 0001-cors-support.-should-fix-COUCHDB-431-2.patch, 0001-cors-support.-should-fix-COUCHDB-431.patch,
0001-cors-support.-should-fix-COUCHDB-431.patch, 0001-cors-support.-should-fix-COUCHDB-431.patch,
0001-cors-support.-should-fix-COUCHDB-431.patch, A_0001-Generalize-computing-the-appropriate-headers-for-any.patch,
A_0002-Send-server-headers-for-externals-responses.patch, A_0003-Usably-correct-w3c-CORS-headers-for-valid-requests.patch,
A_0004-Respond-to-CORS-preflight-checks-HTTP-OPTIONS.patch, check_method_cors.patch, cors.html,
cors_test.html, test_cors2-1.tgz, test_cors2.tgz
> Historically, browsers have been restricted to making XMLHttpRequests (XHRs) to the same
origin (domain) as the web page making the request. However, the latest browsers now support
cross-domain requests by implementing the Access Control spec from the W3C:
> In order to keep older servers safe that assume browsers only do same-domain requests,
the Access Control spec requires the server to opt-in to allow cross domain requests by the
use of special HTTP headers and supporting some "pre-flight" HTTP calls.
> Why should CouchDB support this: in larger, high traffic site, it is common to serve
the static UI files from a separate, differently scaled server complex than the data access/API
server layer. Also, there are some API services that are meant to be centrally hosted, but
allow API consumers to use the API from different domains. In these cases, the UI in the browser
would need to do cross domain requests to access CouchDB servers that act as the API/data
access server layer.
> JSONP is not enough in these cases since it is limited to GET requests, so no POSTing
or PUTing of documents.
> Some information from Firefox's perspective (functionality available as of Firefox 3.5):
> And information on Safari/Webkit (functionality in latest WebKit and Safari 4):
> IE 8 also uses the Access Control spec, but the requests have to go through their XDomainRequest
object (XDR):
> and I thought IE8 only allowed GET or POST requests through their XDR.
> But as far as CouchDB is concerned, implementing the Access Control headers should be
enough, and hopefully IE 9 will allow normal xdomain requests via XHR.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message