Re: [VOTE] Apache CouchDB new docs proposal
Fair enough. On Tue, Nov 29, 2011 at 12:49 AM, Randall Leeds wrote: > On Mon, Nov 28, 2011 at 15:09, Noah Slater wrote: > > Do you think stuff like coding standards, and conventions, might be > better > > documented on the wiki? > > > > I don't have any problem with developer documentation in the source > and installed documentation. For one, as we develop our plugin system > some plugin developers may develop against couch using just the .hrl > files from an installation. These plugins may want to increase their > chance of going upstream by following the project coding conventions. > > > I was seeing this as more of an appendix style look-up for regular > CouchDB > > users. > > > > On Mon, Nov 28, 2011 at 8:24 PM, Joan Touzet wrote: > > > >> On Sat, Nov 26, 2011 at 11:40:41PM +, Noah Slater wrote: > >> > Cool idea. > >> > >> Agreed! As part of the coursework I'm planning for January, I can start > >> contributing back class notes and information as well. This would be the > >> start of documentation about how the code is laid out, formatting, etc. > >> I see this as complementary, and whoever signs up for the course can > >> also contribute at least 30-60 minutes of documentation cleanup as well. > >> > >> If the course is successful, as it is iterated, so too should new groups > >> of students be available to help out as well. With any luck this will be > >> self-sustaining. > >> > >> > I have created a wiki page: > >> > > >> > http://wiki.apache.org/couchdb/SourceDocumentation > >> > >> I'll add this to the wiki right now. > >> > >> -Joan > >> > > >
Re: [VOTE] Apache CouchDB new docs proposal
On Mon, Nov 28, 2011 at 15:09, Noah Slater wrote: > Do you think stuff like coding standards, and conventions, might be better > documented on the wiki? > I don't have any problem with developer documentation in the source and installed documentation. For one, as we develop our plugin system some plugin developers may develop against couch using just the .hrl files from an installation. These plugins may want to increase their chance of going upstream by following the project coding conventions. > I was seeing this as more of an appendix style look-up for regular CouchDB > users. > > On Mon, Nov 28, 2011 at 8:24 PM, Joan Touzet wrote: > >> On Sat, Nov 26, 2011 at 11:40:41PM +, Noah Slater wrote: >> > Cool idea. >> >> Agreed! As part of the coursework I'm planning for January, I can start >> contributing back class notes and information as well. This would be the >> start of documentation about how the code is laid out, formatting, etc. >> I see this as complementary, and whoever signs up for the course can >> also contribute at least 30-60 minutes of documentation cleanup as well. >> >> If the course is successful, as it is iterated, so too should new groups >> of students be available to help out as well. With any luck this will be >> self-sustaining. >> >> > I have created a wiki page: >> > >> > http://wiki.apache.org/couchdb/SourceDocumentation >> >> I'll add this to the wiki right now. >> >> -Joan >> >
[jira] [Created] (COUCHDB-1349) _replicator docs should include the additional info from _active_tasks
_replicator docs should include the additional info from _active_tasks
--
Key: COUCHDB-1349
URL: https://issues.apache.org/jira/browse/COUCHDB-1349
Project: CouchDB
Issue Type: Improvement
Components: Replication
Reporter: Rogutės Sparnuotos
Priority: Minor
There are some nice replication stats at /_active_tasks. I think that these
should be exposed in the corresponding /_replicator documents (well, at least
the first 3):
{
"doc_write_failures": 0,
"docs_read": 0,
"docs_written": 0,
"updated_on": 1322521694,
"started_on": 1322521569
}
This would make it easier to map a replication doc to its status.
This would benefit Futon, which currently seems to have only a limited
interface to /_active_tasks.
This would bring _replicator closer to the old _replicate API, which returns
the stats after one-time replication:
{
"ok": true,
"no_changes": true,
"session_id": "6647e26bc340b706bcf8f3c1ca709846",
"source_last_seq": 95,
"replication_id_version": 2,
"history": [
{
"session_id": "6647e26bc340b706bcf8f3c1ca709846",
"start_time": "Mon, 28 Nov 2011 23:44:28 GMT",
"end_time": "Mon, 28 Nov 2011 23:44:33 GMT",
"start_last_seq": 0,
"end_last_seq": 95,
"recorded_seq": 95,
"missing_checked": 24,
"missing_found": 24,
"docs_read": 24,
"docs_written": 24,
"doc_write_failures": 0
}
]
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Apache CouchDB new docs proposal
Do you think stuff like coding standards, and conventions, might be better documented on the wiki? I was seeing this as more of an appendix style look-up for regular CouchDB users. On Mon, Nov 28, 2011 at 8:24 PM, Joan Touzet wrote: > On Sat, Nov 26, 2011 at 11:40:41PM +, Noah Slater wrote: > > Cool idea. > > Agreed! As part of the coursework I'm planning for January, I can start > contributing back class notes and information as well. This would be the > start of documentation about how the code is laid out, formatting, etc. > I see this as complementary, and whoever signs up for the course can > also contribute at least 30-60 minutes of documentation cleanup as well. > > If the course is successful, as it is iterated, so too should new groups > of students be available to help out as well. With any luck this will be > self-sustaining. > > > I have created a wiki page: > > > > http://wiki.apache.org/couchdb/SourceDocumentation > > I'll add this to the wiki right now. > > -Joan >
Re: [VOTE] Apache CouchDB new docs proposal
On Sat, Nov 26, 2011 at 11:40:41PM +, Noah Slater wrote: > Cool idea. Agreed! As part of the coursework I'm planning for January, I can start contributing back class notes and information as well. This would be the start of documentation about how the code is laid out, formatting, etc. I see this as complementary, and whoever signs up for the course can also contribute at least 30-60 minutes of documentation cleanup as well. If the course is successful, as it is iterated, so too should new groups of students be available to help out as well. With any luck this will be self-sustaining. > I have created a wiki page: > > http://wiki.apache.org/couchdb/SourceDocumentation I'll add this to the wiki right now. -Joan
Re: CORS feature.
On Mon, Nov 28, 2011 at 02:50, Benoit Chesneau wrote:
> On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau wrote:
>> Hi,
>> We had a great discussion today Jason, Randall and me about the CORS
>> feature [1] .
>> I'm positing here the current result that you can find on friendpaste
>> [2] too. I think it's
>> a pretty good start and we can begin to code it. Implementation is
>> mostly a merge
>> between jason proposal and mine imo. Thoughts ?
>>
>> - benoît
>>
>> [1] https://issues.apache.org/jira/browse/COUCHDB-431
>> [2] http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM
>>
>> guidelinees :
>> --
>>
>> - rules shoudl be based on host .
>> - rules depending on the resource :
>> - server : rules defined in .ini
>> - db : rules defined in .db
>>
>> - default cors policy :
>> - allows credential = false
>> - cors enabled
>> - cors can be disabled globaly
>>
>>
>>
>> rules definiton :
>>
>> global wide
>>
>> [httpd]
>> cors_enabled = true
>>
>> [origins]
>> domain.tld = http://origin.tld, https://origin.tld
>>
>> [http://origin.tld]
>> allow_methods = GET, POST
>> allow_headers = x-couchdb-...
>> allow_credentials = false
>>
>>
>> [https://origin.tld]
>> allow_methods = GET, PUT, POST, DELETE
>> allow_headers = x-couchdb-...
>> allow_credentials = true
>> allow_server_admins = true
>> max-age = 36000
>>
>>
>> ond db _security object :
>>
>>
>> {
>> "origins": {
>> "domain.tld": [
>> {"http://origin.tld": { "allow_methods": "GET, POST",
>> ...}
>> ]
>> }
>> }
>>
>>
>>
>> work flow :
>>
>> is origins list empty in ini
>> yes -> is admin party set ?
>> yes -> return "*" , credentials false (with a good caching policy)
>> no -> stop
>> no ->
>> is origin in .ini ?
>> yes ->
>> is origin in list ?
>> yes ->
>> set the cors headers based on .ini
>> then are we on a db resource ?
>> yes ->
>> apply the intersection of .ini with db resource
>> no -> stop
>> no ->
>>
This last bit is wrong, IMO. The paste has an updated version.
I also simplified it just now to distinguish between /db(/...)
resources and "special" paths (/_uuids, etc).
My current suggestion is to use the db _security object when
available, and fall back to .ini config.
This allows admins to configure .ini and never have to touch dbs, but
db administrators can configure their own CORS.
Of course, server admins can still disable cors globally.
I feel like this hits all the use cases. Also the flow in the paste
now explains neatly how a chain of rewrites from dbs A->B->C would
have to check CORS permissions for each db it touches.
http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM
>
>
> quick not about hosts. It should be abble to set '*' to manage origins
> for any hosts.
>
> - benoît
>
[jira] [Closed] (COUCHDB-804) Rename couch_file:make_blocks to couch_file:add_block_prefixes
[ https://issues.apache.org/jira/browse/COUCHDB-804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Somov closed COUCHDB-804. Resolution: Not A Problem No need to fix > Rename couch_file:make_blocks to couch_file:add_block_prefixes > --- > > Key: COUCHDB-804 > URL: https://issues.apache.org/jira/browse/COUCHDB-804 > Project: CouchDB > Issue Type: Improvement > Components: Documentation >Reporter: Andrey Somov >Priority: Trivial > Attachments: couch_file-patch1.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Rename couch_file:make_blocks to couch_file:add_block_prefixes to be > symmetrical with its counterpart - couch_file:remove_block_prefixes > Add a few descriptions for functions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana updated COUCHDB-1289: --- Attachment: 0002-Make-reset_heartbeat-0-a-no-op.patch Added the patch as an attachment instead > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > Labels: patch > Fix For: 1.2 > > Attachments: 0001-Ensure-heartbeats-are-not-skipped.patch, > 0002-Failing-etap-for-heartbeats-skipped.patch, > 0002-Make-reset_heartbeat-0-a-no-op.patch > > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158376#comment-13158376 ] Filipe Manana commented on COUCHDB-1289: Bob, just caught another case where the default TimeoutFun will be called (which stops the streaming immediately): >From 7160021512161e3fa8f83165adc1a64285da6518 Mon Sep 17 00:00:00 2001 From: Filipe David Borba Manana Date: Mon, 28 Nov 2011 12:30:50 + Subject: [PATCH 2/2] Make reset_heartbeat/0 a no-op If no heartbeat option was given, the couch_changes heartbeat function should really be a no-op, that is, to not set the last_changes_heartbeat to the current time, otherwise the default TimeoutFun (when no heartbeat option is given) might be called which causes the changes feed to stop immediately before folding the whole seq tree. --- src/couchdb/couch_changes.erl |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/src/couchdb/couch_changes.erl b/src/couchdb/couch_changes.erl index f124567..72ee346 100644 --- a/src/couchdb/couch_changes.erl +++ b/src/couchdb/couch_changes.erl @@ -531,7 +531,12 @@ get_rest_db_updated(UserAcc) -> end. reset_heartbeat() -> -put(last_changes_heartbeat,now()). +case get(last_changes_heartbeat) of +undefined -> +ok; +_ -> +put(last_changes_heartbeat, now()) +end. maybe_heartbeat(Timeout, TimeoutFun, Acc) -> Before = get(last_changes_heartbeat), -- 1.7.4.4 Do you agree? > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > Labels: patch > Fix For: 1.2 > > Attachments: 0001-Ensure-heartbeats-are-not-skipped.patch, > 0002-Failing-etap-for-heartbeats-skipped.patch > > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158378#comment-13158378 ] Filipe Manana commented on COUCHDB-1289: (Jira messed up with the patch indentation) > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > Labels: patch > Fix For: 1.2 > > Attachments: 0001-Ensure-heartbeats-are-not-skipped.patch, > 0002-Failing-etap-for-heartbeats-skipped.patch > > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-911) Same ocurrence of a document in _bulk_docs generates erroneous conflict messages
[
https://issues.apache.org/jira/browse/COUCHDB-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Dionne updated COUCHDB-911:
---
Fix Version/s: 1.2
> Same ocurrence of a document in _bulk_docs generates erroneous conflict
> messages
>
>
> Key: COUCHDB-911
> URL: https://issues.apache.org/jira/browse/COUCHDB-911
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.0
> Environment: Cloudant BigCouch EC2 node
>Reporter: Jay Nelson
>Assignee: Bob Dionne
>Priority: Minor
> Fix For: 1.2, 1.3
>
> Attachments:
> 0001-Add-test-test-etap-074-doc-update-conflicts.t.patch,
> 0001-Add-test-test-etap-074-doc-update-conflicts.t.patch,
> 0001-Fix-whitespace.patch,
> 0002-Failing-test-for-duplicates-in-bulk-docs.patch,
> 0003-Add-references-to-docs-to-prevent-dups-from-being-co.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Repeating an "_id" in a _bulk_docs post data file results in both entries
> being reported as document conflict errors. The first occurrence actual
> inserts into the database, and only the second occurrence should report a
> conflict.
> curl -d '{ "docs": [ {"_id":"foo"}, {"_id","foo"} ] }' -H
> 'Content-Type:application/json' -X POST
> http://appadvice.cloudant.com/foo/_bulk_docs
> [{"id":"foo","error":"conflict","reason":"Document update
> conflict."},{"id":"foo","error":"conflict","reason":"Document update
> conflict."}]
> But the database shows that one new document was actually inserted.
> Only the second occurrence should report conflict. The first occurrence
> should report the "_rev" property of the newly inserted doc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Dionne updated COUCHDB-1289: Fix Version/s: 1.2 Labels: patch (was: ) > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > Labels: patch > Fix For: 1.2 > > Attachments: 0001-Ensure-heartbeats-are-not-skipped.patch, > 0002-Failing-etap-for-heartbeats-skipped.patch > > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Dionne resolved COUCHDB-1289. - Resolution: Fixed thanks Filipe > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > Labels: patch > Fix For: 1.2 > > Attachments: 0001-Ensure-heartbeats-are-not-skipped.patch, > 0002-Failing-etap-for-heartbeats-skipped.patch > > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CORS feature.
On Mon, Nov 28, 2011 at 11:38 AM, Benoit Chesneau wrote:
> Hi,
> We had a great discussion today Jason, Randall and me about the CORS
> feature [1] .
> I'm positing here the current result that you can find on friendpaste
> [2] too. I think it's
> a pretty good start and we can begin to code it. Implementation is
> mostly a merge
> between jason proposal and mine imo. Thoughts ?
>
> - benoît
>
> [1] https://issues.apache.org/jira/browse/COUCHDB-431
> [2] http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM
>
> guidelinees :
> --
>
> - rules shoudl be based on host .
> - rules depending on the resource :
> - server : rules defined in .ini
> - db : rules defined in .db
>
> - default cors policy :
> - allows credential = false
> - cors enabled
> - cors can be disabled globaly
>
>
>
> rules definiton :
>
> global wide
>
> [httpd]
> cors_enabled = true
>
> [origins]
> domain.tld = http://origin.tld, https://origin.tld
>
> [http://origin.tld]
> allow_methods = GET, POST
> allow_headers = x-couchdb-...
> allow_credentials = false
>
>
> [https://origin.tld]
> allow_methods = GET, PUT, POST, DELETE
> allow_headers = x-couchdb-...
> allow_credentials = true
> allow_server_admins = true
> max-age = 36000
>
>
> ond db _security object :
>
>
> {
> "origins": {
> "domain.tld": [
> {"http://origin.tld": { "allow_methods": "GET, POST",
> ...}
> ]
> }
> }
>
>
>
> work flow :
>
> is origins list empty in ini
> yes -> is admin party set ?
> yes -> return "*" , credentials false (with a good caching policy)
> no -> stop
> no ->
> is origin in .ini ?
> yes ->
> is origin in list ?
> yes ->
> set the cors headers based on .ini
> then are we on a db resource ?
> yes ->
> apply the intersection of .ini with db resource
> no -> stop
> no ->
>
quick not about hosts. It should be abble to set '*' to manage origins
for any hosts.
- benoît
[jira] [Commented] (COUCHDB-1289) heartbeats skipped when continuous changes feed filter function produces no results
[ https://issues.apache.org/jira/browse/COUCHDB-1289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158338#comment-13158338 ] Filipe Manana commented on COUCHDB-1289: Bob, +1. You did most of the hard work, no need to set me as the author for one of them. Lets push it to master and 1.2.x? Thanks :) > heartbeats skipped when continuous changes feed filter function produces no > results > --- > > Key: COUCHDB-1289 > URL: https://issues.apache.org/jira/browse/COUCHDB-1289 > Project: CouchDB > Issue Type: Bug > Components: Database Core >Reporter: Bob Dionne >Assignee: Bob Dionne >Priority: Minor > Attachments: 0001-Ensure-heartbeats-are-not-skipped.patch, > 0002-Failing-etap-for-heartbeats-skipped.patch > > > if the changes feed has a filter function that produces no results, > db_updated messages will still be sent and the heartbeat timeout will never > be reached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
CORS feature.
Hi,
We had a great discussion today Jason, Randall and me about the CORS
feature [1] .
I'm positing here the current result that you can find on friendpaste
[2] too. I think it's
a pretty good start and we can begin to code it. Implementation is
mostly a merge
between jason proposal and mine imo. Thoughts ?
- benoît
[1] https://issues.apache.org/jira/browse/COUCHDB-431
[2] http://friendpaste.com/4q1zeNUEtPFS7XbioPYYzM
guidelinees :
--
- rules shoudl be based on host .
- rules depending on the resource :
- server : rules defined in .ini
- db : rules defined in .db
- default cors policy :
- allows credential = false
- cors enabled
- cors can be disabled globaly
rules definiton :
global wide
[httpd]
cors_enabled = true
[origins]
domain.tld = http://origin.tld, https://origin.tld
[http://origin.tld]
allow_methods = GET, POST
allow_headers = x-couchdb-...
allow_credentials = false
[https://origin.tld]
allow_methods = GET, PUT, POST, DELETE
allow_headers = x-couchdb-...
allow_credentials = true
allow_server_admins = true
max-age = 36000
ond db _security object :
{
"origins": {
"domain.tld": [
{"http://origin.tld": { "allow_methods": "GET, POST",
...}
]
}
}
work flow :
is origins list empty in ini
yes -> is admin party set ?
yes -> return "*" , credentials false (with a good caching policy)
no -> stop
no ->
is origin in .ini ?
yes ->
is origin in list ?
yes ->
set the cors headers based on .ini
then are we on a db resource ?
yes ->
apply the intersection of .ini with db resource
no -> stop
no ->
[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-tabpanel&focusedCommentId=13158270#comment-13158270 ] Benoit Chesneau commented on COUCHDB-431: - preflights requests are done on path. (answring to previous comment) > 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: Benoit Chesneau >Priority: Minor > Fix For: 1.2 > > 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, 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
