Re: [VOTE] Apache CouchDB 1.1.0 release, round 2.
On Mon, May 30, 2011 at 2:23 AM, Dave Cottlehuber d...@muse.net.nz wrote:
On 29 May 2011 05:26, Robert Newson robert.new...@gmail.com wrote:
Hello,
I would like call a vote for the Apache CouchDB 1.1.0 release, round 2.
Thanks Bob all - that is a *lot* of bugs squashed!!
md5, sha, etaps all good.
Mac OS X 10.6.7
NB I needed to do `brew link icu4c` to get couchdb ./configure to work.
ffox passes except for replication {error: not_found}; logs at
http://friendpaste.com/2IS0zh1PjEAmJrgtqWp66u
Swapping R14B01 in for R14B03 - replication tests pass again as
discussed on IRC.
using R14B93, and still have the replication error. Tests with safari
just block on replication and never end. I'm -1 until that's fixed.
Will open/update a ticket with logs.
- benoît
Re: [VOTE] Apache CouchDB 1.1.0 release, round 2.
On 30 May 2011, at 10:50, Benoit Chesneau wrote:
On Mon, May 30, 2011 at 2:23 AM, Dave Cottlehuber d...@muse.net.nz wrote:
On 29 May 2011 05:26, Robert Newson robert.new...@gmail.com wrote:
Hello,
I would like call a vote for the Apache CouchDB 1.1.0 release, round 2.
Thanks Bob all - that is a *lot* of bugs squashed!!
md5, sha, etaps all good.
Mac OS X 10.6.7
NB I needed to do `brew link icu4c` to get couchdb ./configure to work.
ffox passes except for replication {error: not_found}; logs at
http://friendpaste.com/2IS0zh1PjEAmJrgtqWp66u
Swapping R14B01 in for R14B03 - replication tests pass again as
discussed on IRC.
using R14B93, and still have the replication error. Tests with safari
just block on replication and never end. I'm -1 until that's fixed.
Will open/update a ticket with logs.
In case it is unclear, it is R14B03 that introduces this error, 01
and 02 are fine.
Cheers
Jan
--
Re: [VOTE] Apache CouchDB 1.1.0 release, round 2.
I should clarify: the failure on R14B03 is because of a change to OTP.
Specifically, when using cancel:true to stop a running replication
task, we call supervisor:terminate_child and then
supervisor:delete_child. In both cases, we expect 'ok' as the result.
In R14B03, the delete_child call returns {error, not_found} instead.
This lines up with OTP-9167 where they alter the behavior of temporary
child processes. Since these cannot be restarted, they are
automatically deleted once restarted.
I have already applied and tested a fix for this that will be
compatible with all versions.
B.
On 30 May 2011 11:14, Robert Newson robert.new...@gmail.com wrote:
I'm aborting round 2 because of;
1) replication.js failure on R14B03
2) Failure of candidate to build on Windows due to old version of
autoconf/automake
I have fixes for both issues and will release a round 3 candidate soon.
Additional testing, particularly outside of our test suites, is still useful.
B.
On 28 May 2011 19:32, Noah Slater nsla...@apache.org wrote:
Make check ok.
Results from unit tests in Firefox:
* First base on basics caused segfault in CouchDB. Started over with GDB.
* Second time through with cookie_auth failed with file exists message.
* Second time through design_docs caused segfault:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x107c3bc0
0x107c3bc0 in ?? ()
(gdb) backtrace
#0 0x107c3bc0 in ?? ()
Cannot access memory at address 0x107c3bc0
#1 0x7fff8779b5b1 in EVP_DigestInit_ex ()
#2 0x7fff8776989d in ssleay_rand_bytes ()
#3 0x7fff87768f2e in ssleay_rand_pseudo_bytes ()
#4 0x1074307a in rand_bytes_1 ()
#5 0x100fdc07 in process_main ()
#6 0x1006ff5e in sched_thread_func ()
#7 0x1018e8db in thr_wrapper ()
#8 0x7fff833694f6 in _pthread_start ()
#9 0x7fff833693a9 in thread_start ()
* Restarted test suite and got a segfault in basics again:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x107c3bc0
[Switching to process 95309 thread 0x2803]
0x107c3bc0 in ?? ()
(gdb) backtrace
#0 0x107c3bc0 in ?? ()
Cannot access memory at address 0x107c3bc0
#1 0x7fff8779b5b1 in EVP_DigestInit_ex ()
#2 0x7fff8776989d in ssleay_rand_bytes ()
#3 0x7fff87768f2e in ssleay_rand_pseudo_bytes ()
#4 0x1074307a in rand_bytes_1 ()
#5 0x100fdc07 in process_main ()
#6 0x1006ff5e in sched_thread_func ()
#7 0x1018e8db in thr_wrapper ()
#8 0x7fff833694f6 in _pthread_start ()
#9 0x7fff833693a9 in thread_start ()
At least it seems to be the same bit of code that is segfaulting.
I am -1 on the release until we can figure out what's going on here.
Perhaps I have a dodgy SSL library?
I'm not sure how I could check for this, so looking for help!
View query option defaults
Hello list,
Currently, it's necessary to have intimate-ish knowledge of the inner workings
of a view when calling it, e.g.:
http://localhost:5984/mydb/_design/burp/_view/count-laser-beams?group_level=2
If the group level was different, the results returned by the view might be
useless.
Other good examples are include_docs, inclusive_end or descending. For
instance, views that pull in foreign documents by emitting {_id: ...} as a
value will only produce useful results when called with include_docs set to
true.
I'd suggest a feature where inside a view definition, a new key
query_defaults alongside map or reduce contains a hash map of query
option keys and values that will be used when calling the view unless one of
the pre-defined options is passed as a query argument, in which case the
explicitly given query argument would take precedence.
Example:
views: {
talks-by-room: {
map: function(doc) {\n\tif(doc.type == 'talk' doc.date_start)
{\n\t\temit([doc.room, doc.date_start, 0], doc.name);\n\t\tif(doc.speaker)
{\n\t\t\temit([doc.room, doc.date_start, 1], {_id:
doc.speaker});\n\t\t}\n\t}\n};,
query_defaults: {
include_docs: true
}
}
}
http://localhost:5984/couchcamp/_design/burp/_view/talks-by-room would be run
with include_docs=true, but the doc inclusion could be suppressed by requesting
http://localhost:5984/couchcamp/_design/burp/_view/talks-by-room?include_docs=false
Alternative names for the new key are query_options or
query_option_defaults. Whilst I prefer query_options, I think
query_defaults will be the better choice as it underlines the nature of the
functionality - namely, that the options defined therein may be overridden by
the caller.
I'd attempt a patch, but I probably lack the necessary Erlang-fu. Jan
encouraged me to propose the feature here anyway :)
Have a nice week,
David
smime.p7s
Description: S/MIME cryptographic signature
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041182#comment-13041182
]
Alex Chaffee commented on COUCHDB-431:
--
I just encountered this issue myself, and I haven't thought through all the
implications, but isn't there an easier way to crack this nut? If we add a
response_headers config setting to the normal database httpd config, and the
server adds those headers to every HTTP response, then that's it. Admins can
then implement a coarse form of CORS on a per-database level with a simple
{response_headers: {'Access-Control-Allow-Origin': '*'}}.
If more fine-grained control is needed (e.g. allow CORS for some client IP#s
but not others) then a patch like Jason's would be needed. But ACL systems are
notoriously difficult to design and implement. My solution leaves access
control up to the local admin, and also makes it clear just how simple CORS
actually is -- it's not hard security, just a message from the server that
tells the client here's the data, and here's a hint about how I think you
should use it (which hint is ignored by everybody except web browsers).
(cf. Mozilla: The Cross-Origin Resource Sharing standard works by adding new
HTTP headers that allow servers to describe the set of origins that are
permitted to read that information using a web browser. Firefox supports these
headers and enforces the restrictions they establish.
https://developer.mozilla.org/en/http_access_control )
Thoughts?
Support cross domain XMLHttpRequest (XHR) calls by implementing Access
Control spec
---
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: Randall Leeds
Priority: Minor
Attachments:
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, cors.html
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
re: Compact Bug
Yes - the DB was created with 1.0.1 and compacting failed with 1.0.2 Sean, Were you compacting a database created by an older CouchDB version? If so, which? On Wed, May 4, 2011 at 7:28 PM, Halliday, Sean shalli...@ea.com wrote: I have posted a bug that we are getting during compaction cleanup ( https://issues.apache.org/jira/browse/COUCHDB-1147 ) and was wondering if anyone has seen this or knows of a way around it. Keywords: attachments, compaction, bug, CouchDB, badmatch, copy_doc_attachments, couch_db_updater -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org Reasonable men adapt themselves to the world. Â Unreasonable men adapt the world to themselves. Â That's why all progress depends on unreasonable men.
[jira] [Commented] (COUCHDB-1017) HTTP Rewrite Handler: Rewriting strings in queries
[
https://issues.apache.org/jira/browse/COUCHDB-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041309#comment-13041309
]
Markus Barchfeld commented on COUCHDB-1017:
---
Thanks for looking into it. However, I have quite the reverse case: calling a
view with a hierarchical key does not work with quotes.
For example startkey=[2008,08] works fine but startkey=[2008,08] does not
work at all.
Is there a way how I could avoid setting the quotes? Or just any workaround how
I could rewrite the above example from myview/2008/08?
Thanks
HTTP Rewrite Handler: Rewriting strings in queries
--
Key: COUCHDB-1017
URL: https://issues.apache.org/jira/browse/COUCHDB-1017
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Affects Versions: 1.0.1
Reporter: Michel Legnered
Assignee: Benoit Chesneau
Priority: Minor
I have this rewrite:
{
from: /u/:key,
to: _list/pouch/user-items,
method: GET,
query: {key: :key}
}
..where the view returns: {error:bad_request,reason:invalid UTF-8
JSON}. The view query looks like this ?key=somekey, but for the view to
succeed somekey need to be in double quotes.
Maybe one could improve the rewriter's behavior for rewriting strings in
queries?
Here is one workaround:
{
from: /u/:startkey,
to: _list/pouch/user-items,
method: GET,
query: {
startkey: [:startkey],
endkey: [:startkey, {}]
}
},
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] Apache CouchDB 1.1.0 release, round 3.
Hello, I would like call a vote for the Apache CouchDB 1.1.0 release, round 3. Two further issues have been resolved since round 2; 1) Compatibility with erlang R14B03. 2) Release tarball now works on Windows (with Cygwin). We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~rnewson/dist/1.1.0/ These artifacts have been built from the 1.1.0 tag in Subversion: http://svn.apache.org/repos/asf/couchdb/tags/1.1.0 Please follow our test procedure: http://wiki.apache.org/couchdb/Test_procedure Happy voting, B.
Re: [VOTE] Apache CouchDB 1.1.0 release, round 3.
* Signature OK * MD5 OK * SHA1 OK * Make check OK * Futon OK +1 On Mon, May 30, 2011 at 15:25, Robert Newson rnew...@apache.org wrote: Hello, I would like call a vote for the Apache CouchDB 1.1.0 release, round 3. Two further issues have been resolved since round 2; 1) Compatibility with erlang R14B03. 2) Release tarball now works on Windows (with Cygwin). We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~rnewson/dist/1.1.0/ These artifacts have been built from the 1.1.0 tag in Subversion: http://svn.apache.org/repos/asf/couchdb/tags/1.1.0 Please follow our test procedure: http://wiki.apache.org/couchdb/Test_procedure Happy voting, B.
Re: [VOTE] Apache CouchDB 1.1.0 release, round 3.
+1 here. Motions pass on latest OS X. On May 30, 2011, at 8:09 PM, Randall Leeds randall.le...@gmail.com wrote: * Signature OK * MD5 OK * SHA1 OK * Make check OK * Futon OK +1 On Mon, May 30, 2011 at 15:25, Robert Newson rnew...@apache.org wrote: Hello, I would like call a vote for the Apache CouchDB 1.1.0 release, round 3. Two further issues have been resolved since round 2; 1) Compatibility with erlang R14B03. 2) Release tarball now works on Windows (with Cygwin). We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~rnewson/dist/1.1.0/ These artifacts have been built from the 1.1.0 tag in Subversion: http://svn.apache.org/repos/asf/couchdb/tags/1.1.0 Please follow our test procedure: http://wiki.apache.org/couchdb/Test_procedure Happy voting, B.
Re: [VOTE] Apache CouchDB 1.1.0 release, round 3.
On Tue, May 31, 2011 at 12:25 AM, Robert Newson rnew...@apache.org wrote: Hello, I would like call a vote for the Apache CouchDB 1.1.0 release, round 3. Two further issues have been resolved since round 2; 1) Compatibility with erlang R14B03. 2) Release tarball now works on Windows (with Cygwin). We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~rnewson/dist/1.1.0/ These artifacts have been built from the 1.1.0 tag in Subversion: http://svn.apache.org/repos/asf/couchdb/tags/1.1.0 Please follow our test procedure: http://wiki.apache.org/couchdb/Test_procedure Happy voting, B. Ubuntu (10.04): All tests successful. Files=41, Tests=735, 73 wallclock secs ( 0.44 usr 0.11 sys + 18.82 cusr 2.52 csys = 21.89 CPU) Result: PASS FreeBSD: All tests successful. Files=41, Tests=735, 85 wallclock secs (20.09 cusr + 3.78 csys = 23.87 CPU) +1 @Robert: Thanks very, very much for pulling through on this release! This is really, really appreciated! Till
Re: [VOTE] Apache CouchDB 1.1.0 release, round 3.
On 31 May 2011 10:25, Robert Newson rnew...@apache.org wrote: Hello, I would like call a vote for the Apache CouchDB 1.1.0 release, round 3. Two further issues have been resolved since round 2; 1) Compatibility with erlang R14B03. 2) Release tarball now works on Windows (with Cygwin). We encourage the whole community to download and test these release artifacts so that any critical issues can be resolved before the release is made. Everyone is free to vote on this release, so get stuck in! We are voting on the following release artifacts: http://people.apache.org/~rnewson/dist/1.1.0/ These artifacts have been built from the 1.1.0 tag in Subversion: http://svn.apache.org/repos/asf/couchdb/tags/1.1.0 Please follow our test procedure: http://wiki.apache.org/couchdb/Test_procedure Happy voting, B. +1 - md5 ok - sha1 ok Mac OS X 10.6.7 + erlang R14B01 - make check ok - futon ok (via ff 4.0.1 on Mac OS X 10.6.7) Mac OS X 10.6.7 + erlang R14B03 - make check ok - futon ok (via ff 4.0.1 on Mac OS X 10.6.7) Windows 7 Enterprise + erlang R14B01 - make check n/a as usual (note to self to fix this) - futon ok (via ff 4.0.1 on Mac OS X 10.6.7) woo!!! A+ Dave
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041410#comment-13041410 ] Jason Smith commented on COUCHDB-431: - Alex, thanks for your thoughts. Some feedback: I disagree that CORS is not hard security. It is hard security because same-origin is the primary protector of all data on the web. Without same-origin restrictions, any site you visit could reach your data on any other site you visit. It is also hard security in that it is both difficult and important to get right. I am hoping for a fail-safe system. It seems reasonable that the database admin should control the CORS permissions of that database. For a /_config change, that requires the server admin. The _config imposes practical problems too. It is not a general system registry: all the data must go section-key-value. There is no way to have a per-database config except to use an entire new section as a namespace, with each DB name inside it. IMO I don't like that at all. The only place I know of for per-database config is the _security object. Since CORS is about security, it's logical to place it there (where the db admin can modify it). Finally, the original idea that I heard about CORS was to allow people to specify any header. I don't think that is fail-safe. I have no idea what headers people use out there. It seems impossible to evaluate the security of permitting any header for any response. Finally, CORS headers are generally generated dynamically. The only exception is the wildcard header which for CouchDB would be a very dangerous setting. That means any code from any site on any browser can access your couch without the user knowing but (potentially) with the user's couch credentials. Therefore, I am hoping for a whitelist to specify, yes, www.mywebapp.com is my own website and I trust all its code to access this couch. Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec --- 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: Randall Leeds Priority: Minor Attachments: 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, cors.html 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec
[ https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041415#comment-13041415 ] Jason Smith commented on COUCHDB-431: - I am open to the idea of a global (or per-vhost) CORS setting, on the basis that it is simple: easy for users, and easy to reason about. The only problem with this is so much security is already database-oriented. Access and admin permission is per-db. And httpd/secure_rewrites provides isolation inside the DB. Is it going against the grain to do some HTTP security in the server config? With a global config, you could not have /db_A to service webappA.com *only*, and /db_B to service webappB.com *only*. To have two unrelated sites use two unrelated databases, you must run two couches. But still, the simplicity is interesting. Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec --- 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: Randall Leeds Priority: Minor Attachments: 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, cors.html 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. For more information on JIRA, see: http://www.atlassian.com/software/jira
