Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D1BC1DE9A for ; Mon, 5 Nov 2012 17:20:14 +0000 (UTC) Received: (qmail 31700 invoked by uid 500); 5 Nov 2012 17:20:14 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 31574 invoked by uid 500); 5 Nov 2012 17:20:14 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 31473 invoked by uid 99); 5 Nov 2012 17:20:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Nov 2012 17:20:12 +0000 Date: Mon, 5 Nov 2012 17:20:12 +0000 (UTC) From: "Dale Harvey (JIRA)" To: dev@couchdb.apache.org Message-ID: <1210328796.69399.1352136012285.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (COUCHDB-431) cors - aka Cross-Origin Resource Sharing support MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490747#comment-13490747 ] Dale Harvey commented on COUCHDB-431: ------------------------------------- Cheers for this benoitc Off the latest branch everything is working well for my use case, doing to try a few more use cases but this looks good for me, theres a few nits I have and one feature request. 1. enable_cors looks like it has been through a few renames but I am fairly certain its current name is wrong, they are generally declarative so 'cor_enabled = true' Seems right, but if people disagree this pretty minor 2. Some logging would be useful, in particular when requests have been cors disabled due to failing tests against the config 3. There are a lot of features that can be added, (like pattern matched vhosts etc) and I definitely want to avoid adding anything, I think this should be merged as soon as possible, however the one feature that I think would be worth making the cut is wildcard headers, most devs are not going to keep track of every single header that their application uses (and in some cases it will be impossible) so the ability to specify headers = * which just spits back the headers sent by the client would be extremely useful. However I would be happy to see this be merged sans any new features, I will try to get some more uses cases tests and send in any tests + patches Cheers Benoit > cors - aka Cross-Origin Resource Sharing support > ------------------------------------------------- > > Key: COUCHDB-431 > URL: https://issues.apache.org/jira/browse/COUCHDB-431 > Project: CouchDB > Issue Type: New Feature > Components: HTTP Interface > Affects Versions: 0.9 > Reporter: James Burke > Assignee: Benoit Chesneau > Priority: Blocker > Fix For: 1.3 > > 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: > http://dev.w3.org/2006/waf/access-control/ > 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): > https://developer.mozilla.org/en/HTTP_access_control > And information on Safari/Webkit (functionality in latest WebKit and Safari 4): > http://developer.apple.com/safari/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Articles/XHR.html > IE 8 also uses the Access Control spec, but the requests have to go through their XDomainRequest object (XDR): > http://msdn.microsoft.com/en-us/library/cc288060%28VS.85%29.aspx > 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: http://www.atlassian.com/software/jira