[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231397#comment-13231397
 ] 

Randall Leeds commented on COUCHDB-1426:


A quick review of configure.ac has me convinced that the JS_ANONFUNFIX test 
should not fail for lack of finding jsapi.h anymore. +1 for certain. I don't 
see any outstanding failure reports. Okay to merge?

> error while building with 2 spidermonkey installed
> --
>
> Key: COUCHDB-1426
> URL: https://issues.apache.org/jira/browse/COUCHDB-1426
> Project: CouchDB
>  Issue Type: Bug
>  Components: Build System
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Benoit Chesneau
>Assignee: Benoit Chesneau
>Priority: Critical
> Attachments: 0001-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, COUCHDB-1426.patch
>
>
> Context:
> To bench the differences between different versions of couchdb I had to test 
> against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in 
> /usr/local  while the 1.7 version is installed on a temporary path. 
> Problem:
> Using --witth-js-include & --with-js-lib configure options aren't enough to 
> use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing 
> js-config from the path doesn't change anything.  I had to uninstall 
> spidermonkey 1.8.5 to have these setting working.
> Error result:
> $ ./configure 
> --with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include 
> --with-js-include=/Users/benoitc/local/js-1.7.0/include 
> --with-js-lib=/Users/benoitc/local/js-1.7.0/lib64
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking build system type... i386-apple-darwin11.3.0
> checking host system type... i386-apple-darwin11.3.0
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for fgrep... /usr/bin/grep -F
> checking for ld used by gcc... 
> /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
> checking if the linker 
> (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
> checking the name lister (/usr/bin/nm) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 196608
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld 
> option to reload object files... -r
> checking how to recognize dependent libraries... pass_all
> checking for ar... ar
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm output from gcc object... ok
> checking for dsymutil... dsymutil
> checking for nmedit... nmedit
> checking for lipo... lipo
> checking for otool... otool
> checking for otool64... no
> checking for -single_module linker flag... yes
> checking for -exported_symbols_list linker flag... yes
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fno-common -DPIC
> checking if gcc PIC flag -fno-common -DPIC works..

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231256#comment-13231256
 ] 

Randall Leeds commented on COUCHDB-1426:


The only improvement I'd like to see, if possible, is a way to disambiguate 
path issues from non-declaration of the JS_ANONFUNFIX. For me, I had to dig 
into config.log. Is there an improvement we could make so that a test for 
jsapi.h fails first? I think we already have that, but we were missing some 
branch which properly set the CPPFLAGS. I'm pretty sure we're good to go, but I 
figured I would mention it.  

+1 to merge. 

> error while building with 2 spidermonkey installed
> --
>
> Key: COUCHDB-1426
> URL: https://issues.apache.org/jira/browse/COUCHDB-1426
> Project: CouchDB
>  Issue Type: Bug
>  Components: Build System
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Benoit Chesneau
>Assignee: Benoit Chesneau
>Priority: Critical
> Attachments: 0001-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, COUCHDB-1426.patch
>
>
> Context:
> To bench the differences between different versions of couchdb I had to test 
> against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in 
> /usr/local  while the 1.7 version is installed on a temporary path. 
> Problem:
> Using --witth-js-include & --with-js-lib configure options aren't enough to 
> use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing 
> js-config from the path doesn't change anything.  I had to uninstall 
> spidermonkey 1.8.5 to have these setting working.
> Error result:
> $ ./configure 
> --with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include 
> --with-js-include=/Users/benoitc/local/js-1.7.0/include 
> --with-js-lib=/Users/benoitc/local/js-1.7.0/lib64
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking build system type... i386-apple-darwin11.3.0
> checking host system type... i386-apple-darwin11.3.0
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for fgrep... /usr/bin/grep -F
> checking for ld used by gcc... 
> /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
> checking if the linker 
> (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
> checking the name lister (/usr/bin/nm) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 196608
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld 
> option to reload object files... -r
> checking how to recognize dependent libraries... pass_all
> checking for ar... ar
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm output from gcc object... ok
> checking for dsymutil... dsymutil
> checking for nmedit... nmedit
> checking for lipo... lipo
> checking for otool... otool
> checking for otool64... no
> checking for -single_module linker flag... yes
> checking for -exported_symbols_list linker flag... yes
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checkin

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231181#comment-13231181
 ] 

Randall Leeds commented on COUCHDB-1426:


Current branch works beautifully for me.  Global 1.8.5 installed is 
auto-detected, using only --with-js-include and -lib only I'm able to build 
against both 1.7.0 or 1.8.0.

> error while building with 2 spidermonkey installed
> --
>
> Key: COUCHDB-1426
> URL: https://issues.apache.org/jira/browse/COUCHDB-1426
> Project: CouchDB
>  Issue Type: Bug
>  Components: Build System
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Benoit Chesneau
>Assignee: Benoit Chesneau
>Priority: Critical
> Attachments: 0001-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, COUCHDB-1426.patch
>
>
> Context:
> To bench the differences between different versions of couchdb I had to test 
> against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in 
> /usr/local  while the 1.7 version is installed on a temporary path. 
> Problem:
> Using --witth-js-include & --with-js-lib configure options aren't enough to 
> use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing 
> js-config from the path doesn't change anything.  I had to uninstall 
> spidermonkey 1.8.5 to have these setting working.
> Error result:
> $ ./configure 
> --with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include 
> --with-js-include=/Users/benoitc/local/js-1.7.0/include 
> --with-js-lib=/Users/benoitc/local/js-1.7.0/lib64
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking build system type... i386-apple-darwin11.3.0
> checking host system type... i386-apple-darwin11.3.0
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for fgrep... /usr/bin/grep -F
> checking for ld used by gcc... 
> /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
> checking if the linker 
> (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
> checking the name lister (/usr/bin/nm) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 196608
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld 
> option to reload object files... -r
> checking how to recognize dependent libraries... pass_all
> checking for ar... ar
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm output from gcc object... ok
> checking for dsymutil... dsymutil
> checking for nmedit... nmedit
> checking for lipo... lipo
> checking for otool... otool
> checking for otool64... no
> checking for -single_module linker flag... yes
> checking for -exported_symbols_list linker flag... yes
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for dlfcn.h... yes
> checking for objdir... .libs
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fno-common -DPIC
> checking if gcc PIC flag -fno-common -DPIC works... yes
> checking if gcc static f

[jira] [Commented] (COUCHDB-1426) error while building with 2 spidermonkey installed

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229669#comment-13229669
 ] 

Randall Leeds commented on COUCHDB-1426:


For me, auto-detection of my libmozjs185 works fine, but the checks are wrong.
In particular, the AC_CHECK_DECL for JS_ANONFUNFIX says it's not defined. 
However, config.log reveals that's because 'jsapi.h' can't be found. The header 
is in /usr/include/js, but that's not being included in the search path.

I thought a fix would be to amend the PKG_CONFIG success case for libmozjs185 
to set $JS_INCLUDE.

However, now I'm having compilation errors on couchjs, but no problems on an 
unpatched 1.2.x. I'll report back when I figure out what the difference is.

> error while building with 2 spidermonkey installed
> --
>
> Key: COUCHDB-1426
> URL: https://issues.apache.org/jira/browse/COUCHDB-1426
> Project: CouchDB
>  Issue Type: Bug
>  Components: Build System
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Benoit Chesneau
>Assignee: Benoit Chesneau
>Priority: Critical
> Attachments: 0001-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, 
> 0001-fix-build-with-custom-path-close-COUCHDB-1426.patch, COUCHDB-1426.patch
>
>
> Context:
> To bench the differences between different versions of couchdb I had to test 
> against spidermonkey 1.7 and 1.8.5 . 1.8.5 is installed globally in 
> /usr/local  while the 1.7 version is installed on a temporary path. 
> Problem:
> Using --witth-js-include & --with-js-lib configure options aren't enough to 
> use the 1.7 version it still want to use spidermonkey 1.8.5 . Removing 
> js-config from the path doesn't change anything.  I had to uninstall 
> spidermonkey 1.8.5 to have these setting working.
> Error result:
> $ ./configure 
> --with-erlang=/Users/benoitc/local/otp-r14b04/lib/erlang/usr/include 
> --with-js-include=/Users/benoitc/local/js-1.7.0/include 
> --with-js-lib=/Users/benoitc/local/js-1.7.0/lib64
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for a thread-safe mkdir -p... build-aux/install-sh -c -d
> checking for gawk... no
> checking for mawk... no
> checking for nawk... no
> checking for awk... awk
> checking whether make sets $(MAKE)... yes
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ISO C89... none needed
> checking for style of include used by make... GNU
> checking dependency style of gcc... gcc3
> checking build system type... i386-apple-darwin11.3.0
> checking host system type... i386-apple-darwin11.3.0
> checking for a sed that does not truncate output... /usr/bin/sed
> checking for grep that handles long lines and -e... /usr/bin/grep
> checking for egrep... /usr/bin/grep -E
> checking for fgrep... /usr/bin/grep -F
> checking for ld used by gcc... 
> /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld
> checking if the linker 
> (/usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld) is GNU ld... no
> checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
> checking the name lister (/usr/bin/nm) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 196608
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking for /usr/llvm-gcc-4.2/libexec/gcc/i686-apple-darwin11/4.2.1/ld 
> option to reload object files... -r
> checking how to recognize dependent libraries... pass_all
> checking for ar... ar
> checking for strip... strip
> checking for ranlib... ranlib
> checking command to parse /usr/bin/nm output from gcc object... ok
> checking for dsymutil... dsymutil
> checking for nmedit... nmedit
> checking for lipo... lipo
> checking for otool... otool
> checking for otool64... no
> checking for -single_module linker flag... yes
> checking for -exported_symbols_list linker flag... yes
> checking how to run the C preprocessor... gcc -E
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> che

[jira] [Commented] (COUCHDB-890) Option to use a persistent CommonJS module cache

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13209840#comment-13209840
 ] 

Randall Leeds commented on COUCHDB-890:
---

Osher, the best way to get real-time support is to find developers in IRC in 
the #couchdb room on Freenode.
The wiki has build documentation.
The main.js script the server runs is in the directory share/server. Those 
files are all concatenated at build time (see Makefile.am in that directory) 
and output to the file main.js.
To debug you can try to run the file directly with the couchjs program and 
pretend to be the CouchDB side of the View Server Protocol, which you can also 
find on the wiki.

> Option to use a persistent CommonJS module cache
> 
>
> Key: COUCHDB-890
> URL: https://issues.apache.org/jira/browse/COUCHDB-890
> Project: CouchDB
>  Issue Type: Improvement
>  Components: JavaScript View Server
> Environment: All
>Reporter: mikeal
> Attachments: commonjscache.diff
>
>
> Since COUCHDB-1075, there is a CommonJS module cache used for resolving 
> circular CommonJS dependencies. However, Caolan reports a 10x speed 
> improvement by not clearing this cache between requests. An option to not 
> clear the cache could be a great tool for performance-interested power users 
> who know their CommonJS modules are sane. The improvement will be even 
> greater when we turn on the JIT compiler in SpiderMonkey since cached modules 
> will benefit from being pre-JIT'd.

--
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-1396) Deleting a conflict revision will return a wrong current doc revision

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13196456#comment-13196456
 ] 

Randall Leeds commented on COUCHDB-1396:


This is intended behavior. DELETE is just an update in CouchDB which sets the 
new revision to have a {_deleted: true} flag.
If you request 
$COUCH/db2/doc?rev=2-f4a2a6b0c7742a5e6dd7eea7a4b625a1&deleted=true you should 
see this tombstone update.

Similarly, if you update a non-winning conflict it should return you the new 
revision of that branch whether or not it is the winning branch. Updates return 
the revision of the update, not the winning revision of the document (in the 
case that they are different).

> Deleting a conflict revision will return a wrong current doc revision
> -
>
> Key: COUCHDB-1396
> URL: https://issues.apache.org/jira/browse/COUCHDB-1396
> Project: CouchDB
>  Issue Type: Bug
>  Components: Replication
>Reporter: Oliver Kurowski
>Priority: Minor
>  Labels: conflict, replication, revision
>
> After deleting the current revision to make the conflict revision the winning 
> one, 
> the returned revisionnummer ("2-f4a2a6b0c7742a5e6dd7eea7a4b625a1") is not the 
> revision number of the documen (1-45c1922c1b51dc5ee945218d63ce2ab4) 
> echo $COUCH curly -X 
> DELETE $COUCH/db1 curly -X 
> DELETE $COUCH/db2 curly -X 
> PUT $COUCH/db1 
> curly -X PUT $COUCH/db2 
> curly -X PUT $COUCH/db1/doc -d '{"wert":1}' 
> curly -X PUT $COUCH/db2/doc -d '{"wert":2}' 
> curly -X POST $COUCH/_replicate -d '{"source":"db1","target":"db2"}' 
> curly $COUCH/db2/doc\?conflicts=true 
> curly $COUCH/db2/doc\?revs=true 
> curly -X DELETE $COUCH/db2/doc\?rev=1-97cea70a7b8b41aae9e5732f4ac7 
> curly $COUCH/db2/doc\?conflicts=true 
> curly $COUCH/db2/doc\?revs=true curly $COUCH/db2/doc
> sendai ~ % echo $COUCH http://localhost:5984 
> sendai ~ % curly -X DELETE $COUCH/db1 
> {"ok" : true } 
> sendai ~ % curly -X DELETE $COUCH/db2 
> {"ok" : true } 
> sendai ~ % curly -X PUT $COUCH/db1 
> {"ok" : true } 
> sendai ~ % curly -X PUT $COUCH/db2 
> {"ok" : true } 
> sendai ~ % curly -X PUT $COUCH/db1/doc -d '{"wert":1}' 
> {"ok" : true,"rev" : "1-97cea70a7b8b41aae9e5732f4ac7","id" : 
> "doc" } 
> sendai ~ % curly -X PUT $COUCH/db2/doc -d '{"wert":2}' 
> {"ok" : true,"rev" : "1-45c1922c1b51dc5ee945218d63ce2ab4","id" : 
> "doc" } 
> sendai ~ % curly -X POST $COUCH/_replicate -d 
> '{"source":"db1","target":"db2"}' 
> {"ok" : true,"history" : [   {  "docs_read" : 1,  
> "session_id" : "7c74c9bb9f322e10ad072215e823c2d8",  "recorded_seq" : 
> 1,  "end_last_seq" : 1,  "doc_write_failures" : 0,  
> "start_time" : "Mon, 30 Jan 2012 20:34:18 GMT",  "start_last_seq" : 
> 0,  "end_time" : "Mon, 30 Jan 2012 20:34:18 GMT",  
> "missing_checked" : 0,  "docs_written" : 1,  "missing_found" 
> : 1   }],"session_id" : "7c74c9bb9f322e10ad072215e823c2d8",
> "source_last_seq" : 1,"replication_id_version" : 2 } 
> sendai ~ % curly $COUCH/db2/doc\?conflicts=true 
> {"_id" : "doc","wert" : 1,"_conflicts" : [   
> "1-45c1922c1b51dc5ee945218d63ce2ab4"],"_rev" : 
> "1-97cea70a7b8b41aae9e5732f4ac7" } 
> sendai ~ % curly $COUCH/db2/doc\?revs=true 
> {"_id" : "doc","wert" : 1,"_revisions" : {   "ids" : [
>   "97cea70a7b8b41aae9e5732f4ac7"   ],   "start" : 1},
> "_rev" : "1-97cea70a7b8b41aae9e5732f4ac7" } 
> sendai ~ % curly -X DELETE 
> $COUCH/db2/doc\?rev=1-97cea70a7b8b41aae9e5732f4ac7
> {"ok" : true,"rev" : "2-f4a2a6b0c7742a5e6dd7eea7a4b625a1","id" : 
> "doc" } 
>
> 
> sendai ~ % curly $COUCH/db2/doc\?conflicts=true {"_id" : "doc","wert" 
> : 2,"_rev" : "1-45c1922c1b51dc5ee945218d63ce2ab4" } 
> sendai ~ % curly $COUCH/db2/doc\?revs=true {"_id" : "doc","wert" : 2, 
>"_revisions" : {   "ids" : [  
> "45c1922c1b51dc5ee945218d63ce2ab4"   ],   "start" : 1},"_rev" 
> : "1-45c1922c1b51dc5ee945218d63ce2ab4" } 
> sendai ~ % curly $COUCH/db2/doc {"_id" : "doc","wert" : 2,"_rev" 
> : "1-45c1922c1b51dc5ee945218d63ce2ab4" } 
> sendai ~ % 

--
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-1133) Fix opacity on favicon

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195982#comment-13195982
 ] 

Randall Leeds commented on COUCHDB-1133:


Okay, clearly _this_ patch has sat here too long for how trivial it is.
But, I don't understand the .patch file... why are those lines removed, 
Benjamin?

> Fix opacity on favicon
> --
>
> Key: COUCHDB-1133
> URL: https://issues.apache.org/jira/browse/COUCHDB-1133
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Futon
>Reporter: Dale Harvey
>Priority: Trivial
> Attachments: bjw_1133.patch, favicon.ico, favicon.png
>
>
> Fix the opacity on the favicon so it doesnt look awkward on non white browser 
> chrome

--
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-1395) Not well-formed JSON in changes feed filtered by view.

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195648#comment-13195648
 ] 

Randall Leeds commented on COUCHDB-1395:


I would advise that we wait for Benoit to publish the work he's started on 
refactoring the httpd core. Benoit, any ETA on a proof of concept there?

> Not well-formed JSON in changes feed filtered by view.
> --
>
> Key: COUCHDB-1395
> URL: https://issues.apache.org/jira/browse/COUCHDB-1395
> Project: CouchDB
>  Issue Type: Bug
>Affects Versions: 1.2, 1.3
> Environment: Apache CouchDB 1.3.0a-d59cdd7-git
> Apache CouchDB 1.2.0a-0d8ddc8-git
>Reporter: Alexander Shorin
>Priority: Critical
> Attachments: filtered_view_bug.sh
>
>
> CouchDB returns invalid JSON response for _changes feed if filter view have 
> failed somehow: by code mistake, bug, os timeout etc.
> Steps to reproduce:
> 1. Create db and fill it with some documents.
> 2. Create buggy view that would make view server crush for some document. For 
> javascript one segfault and os timeout errors are actual due to any 
> exceptions raised from map function is silenced.  You view could be fine 
> however for normal usage.
> 3.  Request changes feed and apply this buggy view as filter.
> Story:
> View function had never proceed design documents and mostly they are created 
> with that knowledge. But in changes feed they have to process every document 
> in database and DDocs too, so they breaks their original logic and creates 
> unexpectable situation. Another side of problem is about custom query servers 
> that could prevent view processing on first occurred exception or due dynamic 
> code execution nature.
> Certainly,  it's all about invalid view function that generates exception for 
> some document in some case, but should _changes feed return malformed data in 
> this case or just notify about problem somehow and emit valid parseable JSON?
> Expected result:
> Valid JSON response and some message about document processing error.
> Actual result:
> * About to connect() to localhost port 5984 (#0)
> *   Trying 127.0.0.1... connected
> * Connected to localhost (127.0.0.1) port 5984 (#0)
> > GET /filtered_view_bug/_changes?filter=_view&view=bug/crush_on_ddoc HTTP/1.1
> > User-Agent: curl/7.21.4 (x86_64-pc-linux-gnu) libcurl/7.21.4 GnuTLS/2.10.5 
> > zlib/1.2.5
> > Host: localhost:5984
> > Accept: application/json
> > 
> < HTTP/1.1 200 OK
> < Transfer-Encoding: chunked
> < Server: CouchDB/1.3.0a-d59cdd7-git (Erlang OTP/R14B04)
> < ETag: "3IV66Q7INUYEHYKVWADD0CA8A"
> < Date: Thu, 26 Jan 2012 19:30:23 GMT
> < Content-Type: application/json
> < Cache-Control: must-revalidate
> < 
> {"results":[
> {"seq":1,"id":"foo","changes":[{"rev":"1-5277061607e266deb7cc87eb63354db7"}]},
> {"seq":2,"id":"bar","changes":[{"rev":"1-ced1ed0168f00311e1ee301cda904840"}]},
> {"seq":3,"id":"baz","changes":[{"rev":"1-ae16db0d925a8295009ff580e226a978"}]}
> * Received problem 2 in the chunky parser
> * Closing connection #0
> curl: (56) Received problem 2 in the chunky parser
> Last chunk arrives with "HTTP/1.1 500 Internal Server Error" instead of size 
> value.

--
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-1391) Implement _security as _local doc with revision trees

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13195219#comment-13195219
 ] 

Randall Leeds commented on COUCHDB-1391:


Cool. Good plans. You're right not to go crazy with refactoring yet.

I think update_local_docs needs the privileged #db handle, you should just take 
the local_docs_btree from the #db it returns and put that into the original 
handle passed into init_security.

> Implement _security as _local doc with revision trees
> -
>
> Key: COUCHDB-1391
> URL: https://issues.apache.org/jira/browse/COUCHDB-1391
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Reporter: Paul Joseph Davis
> Attachments: 0001-Refactor-revision-merging.patch, 
> 0002-Replace-_local-doc-sequence-with-revision-trees.patch, 
> 0003-Prevent-multiple-updates-to-a-single-_local-doc.patch, 
> 0004-Implement-_security-as-a-_local-doc.patch
>
>
> We had a discussion [1] a while back about updating the _security object so 
> that it could be replicated (internally) in a cluster or similar environment. 
> The basic gist was "update _local docs to have a revision tree, update 
> _security to be a _local doc with docid "_local/_security" and keep the 
> current _security API for a version or two for backwards compatibility (or 
> forever, what color is your bike shed?)"
> So I did that.
> Basic patch progression is:
> 1. Refactor revision merging logic so that we can split it out of 
> couch_db_updater's code path for updating normal docs.
> 2. Implement _local docs with #full_doc_info{} records (and thus revision 
> trees)
> 3. Implement _security as _local/_security
> These things are done. Tests should theoretically pass after each patch but I 
> haven't gone back and tried. They definitely pass (minus auth_cache which I 
> just submitted a fix for) now except for replication.js appears to fail for 
> random reasons. I can't quite decide if I've introduced this or if it just 
> fails randomly. Rather than run it a lot more times and continue to be 
> confused I'm starting this ticket so I can have other people test and tell me 
> their results.
> Also, the test suite is rather wonky on trunk with segfaults. We should 
> really look into that more.
> Patches forth coming. I've also pushed the branch to [2].
> [1] 
> http://grokbase.com/t/couchdb.apache.org/dev/2011/08/the-security-object-should-be-versioned/17rfmmtlu3lagqvgyq7cay26dqk4
> [2] 
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=refs/heads/new-security-object

--
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-1391) Implement _security as _local doc with revision trees

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194289#comment-13194289
 ] 

Randall Leeds commented on COUCHDB-1391:


Can you explain couch_db.erl:705? Why did the list brackets appear around the 
doc? I'm guessing that's the format new_revs wants.

For couch_db:open_doc_int/3 I would remove the first function clause entirely 
and then add a clause to get_doc_infos/2. That cleanly splits the logic at the 
choice of btree and introduces less redundant code for us to mess up down the 
line.

In couch_db_updater:init_db/6 the line "Db1#db{security_ptr=local};" is 
redundant in the clause where security_ptr is already the atom local.
Am I right that at these lines update a db as soon as it's opened? I was 
wondering why I didn't see more backwards-compatibility code anywhere. Just 
want to know I've got it right.

couch_db_updater:init_security/2 needs to be fixed to keep the user context 
intact, I think. Right now it sets the user context to _admin so it can update 
the security document but then returns that modified #db record back to init_db 
without dropping those privileges. Unless I misunderstand, that seems wrong.

Any reason why copy_docs can't be changed to take a btree argument? It looks 
mostly the same as copy_local_docs.

What's the change in couch_replicator? The second clause doesn't make total 
sense to me. Is that to reset the leading number for the rev when the log is 
migrated to a new ID?

Otherwise, nicely done! Looks great! Thanks.

> Implement _security as _local doc with revision trees
> -
>
> Key: COUCHDB-1391
> URL: https://issues.apache.org/jira/browse/COUCHDB-1391
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Reporter: Paul Joseph Davis
> Attachments: 0001-Refactor-revision-merging.patch, 
> 0002-Replace-_local-doc-sequence-with-revision-trees.patch, 
> 0003-Prevent-multiple-updates-to-a-single-_local-doc.patch, 
> 0004-Implement-_security-as-a-_local-doc.patch
>
>
> We had a discussion [1] a while back about updating the _security object so 
> that it could be replicated (internally) in a cluster or similar environment. 
> The basic gist was "update _local docs to have a revision tree, update 
> _security to be a _local doc with docid "_local/_security" and keep the 
> current _security API for a version or two for backwards compatibility (or 
> forever, what color is your bike shed?)"
> So I did that.
> Basic patch progression is:
> 1. Refactor revision merging logic so that we can split it out of 
> couch_db_updater's code path for updating normal docs.
> 2. Implement _local docs with #full_doc_info{} records (and thus revision 
> trees)
> 3. Implement _security as _local/_security
> These things are done. Tests should theoretically pass after each patch but I 
> haven't gone back and tried. They definitely pass (minus auth_cache which I 
> just submitted a fix for) now except for replication.js appears to fail for 
> random reasons. I can't quite decide if I've introduced this or if it just 
> fails randomly. Rather than run it a lot more times and continue to be 
> confused I'm starting this ticket so I can have other people test and tell me 
> their results.
> Also, the test suite is rather wonky on trunk with segfaults. We should 
> really look into that more.
> Patches forth coming. I've also pushed the branch to [2].
> [1] 
> http://grokbase.com/t/couchdb.apache.org/dev/2011/08/the-security-object-should-be-versioned/17rfmmtlu3lagqvgyq7cay26dqk4
> [2] 
> http://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=log;h=refs/heads/new-security-object

--
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-1393) badmatch on big binary

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193295#comment-13193295
 ] 

Randall Leeds commented on COUCHDB-1393:


And any history of solar storms in the area. ;)
Seriously, fsync is no match for a bad sector or a cosmic ray.

> badmatch on big binary
> --
>
> Key: COUCHDB-1393
> URL: https://issues.apache.org/jira/browse/COUCHDB-1393
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Jan Lehnardt
>
> via dev@ by Peta Bogdan 
> Hello,
> I have a small database around 120 MB with approximately 16,000 documents.
> However, it happens (also from futon) that I get this error:
> [Tue, 17 Jan 2012 07:22:01 GMT] [error] [<0.185.0>] {error_report,<0.30.0>,
> {<0.185.0>,crash_report,
>  [[{initial_call,{couch_file,init,['Argument__1']}},
>{pid,<0.185.0>},
>{registered_name,[]},
>{error_info,
> {exit,
>  {{badmatch,
>{ok,
> 9_MEGABYTES_BINARY}},
>   [{couch_file,read_raw_iolist_int,3},
>{couch_file,maybe_read_more_iolist,4},
>{couch_file,handle_call,3},
>{gen_server,handle_msg,5},
>{proc_lib,init_p_do_apply,3}]},
>  [{gen_server,terminate,6},
>   {proc_lib,init_p_do_apply,3}]}},
>{ancestors,[<0.184.0>]},
>{messages,
> [{'$gen_call',
>   {<0.10840.18>,#Ref<0.0.3.20907>},
>   bytes}]},
>{links,[<0.190.0>]},
>{dictionary,[]},
>{trap_exit,true},
>{status,running},
>{heap_size,1597},
>{stack_size,24},
>{reductions,65666}],
>   [{neighbour,
> [{pid,<0.190.0>},
>  {registered_name,[]},
>  {initial_call,
>   {couch_ref_counter,init,['Argument__1']}},
>  {current_function,{gen_server,loop,6}},
>  {ancestors,[<0.188.0>,<0.187.0>,<0.184.0>]},
>  {messages,[]},
>  {links,[<0.185.0>]},
>  {dictionary,[]},
>  {trap_exit,false},
>  {status,waiting},
>  {heap_size,610},
>  {stack_size,9},
>  {reductions,362}]}]]}}
> If this error occurs to frequently causes couch_server to reach its max
> restart frequency causing the entire supervision tree to shutdown and hence
> the database server instance disappears.
> The function couch_file:read_raw_iolist_int/3 calls file:pread which
> returns {ok, Binary}. This Binary has almost 9 megabytes in size, which is
> very strange.
> I think this does mean that the function file:pread/3 is instructed to read
> from wrong position.
> The only reason I can think of is that the value of 'TotalBytes' from line
> (1) doesn't match the value of 'TotalBytes' from line (2)
> (1) TotalBytes = calculate_total_read_len(BlockOffset, Len),
> (2) {ok, <>} = file:pread(Fd, Pos, TotalBytes),
> The possible answer would be that in certain conditions the function
> calculate_total_read_len/2 doesn't return the expected value.
> Server: CouchDB/1.1.1 (Erlang OTP/R14B04)
> OS: OpenBSD 5.0 GENERIC.MP#63 amd64
> Now, the trouble is how to circumvent this situation.
> Thank you in advance,
> Bogdan

--
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-1390) Fix auth_cache etap test

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192937#comment-13192937
 ] 

Randall Leeds commented on COUCHDB-1390:


Looks good. Would it be appropriate to back-port it to 1.2 to prevent any noise 
it might cause during voting?

> Fix auth_cache etap test
> 
>
> Key: COUCHDB-1390
> URL: https://issues.apache.org/jira/browse/COUCHDB-1390
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Paul Joseph Davis
> Attachments: COUCHDB-1390.patch
>
>
> The auth_cache etap tests were failing for me. Debugged this to make sure it 
> wasn't related to something else. Commit message is:
> Fix for the auth_cache etap
> 
> As it turns out, opening a doc by id is different than opening it using
> a #doc_info record due to the inclusion of the full revision path. This
> ended up breaking the auth_cache tests. This way includes the entire
> revision path for all docs and not just first doc loads.
> Patching attaching in a few moments.

--
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-1389) Improve JS CLI test error reports

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13192933#comment-13192933
 ] 

Randall Leeds commented on COUCHDB-1389:


How's that compare to what I did on my branch[1] here: 
https://github.com/tilgovi/couchdb/commit/0668c982aa1338ca40fce2b83a742489f33128a5#L4L18

[1] https://github.com/tilgovi/couchdb/compare/master...jssauce

> Improve JS CLI test error reports
> -
>
> Key: COUCHDB-1389
> URL: https://issues.apache.org/jira/browse/COUCHDB-1389
> Project: CouchDB
>  Issue Type: Improvement
>Reporter: Paul Joseph Davis
> Attachments: COUCHDB-1389.patch
>
>
> About to attach a simple patch that gives better error output when JS tests 
> fail.

--
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-1378) Installing on OSX wiki page incorrect

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191872#comment-13191872
 ] 

Randall Leeds commented on COUCHDB-1378:


Jason, if you give us your wiki user name we can add you to the contributors 
group so you can correct this. Thanks!

> Installing on OSX wiki page incorrect
> -
>
> Key: COUCHDB-1378
> URL: https://issues.apache.org/jira/browse/COUCHDB-1378
> Project: CouchDB
>  Issue Type: Bug
>  Components: Documentation
>Reporter: Jason Sachs
>Priority: Minor
>
> http://wiki.apache.org/couchdb/Installing_on_OSX lists two sources for OSX 
> binaries; neither are valid anymore (2nd one doesn't exist, 1st one just 
> points to Couchbase Single Server, which does have binaries for OSX but they 
> don't work and Couchbase isn't supporting Single Server anymore.)

--
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-822) body_too_large error for external processes, when body is 3MB

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13191871#comment-13191871
 ] 

Randall Leeds commented on COUCHDB-822:
---

Bob, if you can confirm what Jason says this appears fixed for 1.2. Update NEWS 
and CHANGES if necessary.

> body_too_large error for external processes, when body is 3MB
> -
>
> Key: COUCHDB-822
> URL: https://issues.apache.org/jira/browse/COUCHDB-822
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 0.11
> Environment: CouchDB 0.11 on Ubuntu 10.04,
>Reporter: Erik Edin
>Assignee: Robert Newson
>Priority: Minor
> Fix For: 1.3
>
>
> I have a photo which is around 3 MB that I'm trying to PUT to an external 
> process on the CouchDB database. The external process is called "_upload".
> I get an uncaught error "{exit,{body_too_large,content_length}}" in the logs 
> when trying this. Smaller photos (around 60 kB) seem to work just fine.
> This just happens with external processes. I can upload the photo as an 
> attachment directly to a document, with no problems.
> The error is similar to an earlier bug in the mochiweb library that was fixed 
> around Feb 2009, where mochiweb never used the "max_document_size" setting 
> that was provided when calling mochiweb_request:recv_body.
> I believe, supported by the stack trace below, that the cause for this bug is 
> that in couch_httpd_external:json_req_obj the function 
> mochiweb_request:recv_body/0 is called, which uses the mochiweb default value 
> on MaxBody, which is 1 MB.
> I think that couch_httpd_external:json_req_obj should call 
> mochiweb_request:recv_body/1 instead, with the "max_document_size" setting as 
> the argument.
> Here are the error logs from one of my attempts:
> [Thu, 08 Jul 2010 18:49:53 GMT] [debug] [<0.3738.0>] 'PUT' 
> /pillowfight/_upload/6b1908c352129ddda396fa69ac003d11 {1,1}
> Headers: [{'Accept',"*/*"},
>   {'Content-Length',"3093976"},
>   {'Content-Type',"image/jpg"},
>   {"Expect","100-continue"},
>   {'Host',"localhost:5984"},
>   {'User-Agent',"curl/7.19.7 (i486-pc-linux-gnu) libcurl/7.19.7 
> OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15"}]
> [Thu, 08 Jul 2010 18:49:53 GMT] [debug] [<0.3738.0>] OAuth Params: []
> [Thu, 08 Jul 2010 18:49:53 GMT] [error] [<0.3738.0>] Uncaught error in HTTP 
> request: {exit,{body_too_large,content_length}}
> [Thu, 08 Jul 2010 18:49:53 GMT] [info] [<0.3738.0>] Stacktrace: 
> [{mochiweb_request,stream_body,5},
>  {mochiweb_request,recv_body,2},
>  {couch_httpd_external,json_req_obj,3},
>  {couch_httpd_external,process_external_req,3},
>  {couch_httpd_db,do_db_req,2},
>  {couch_httpd,handle_request_int,5},
>  {mochiweb_http,headers,5},
>  {proc_lib,init_p_do_apply,3}]

--
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-592) Build and configure without the js library

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190950#comment-13190950
 ] 

Randall Leeds commented on COUCHDB-592:
---

If anyone wants to take this task on, the first thing would be to find all the 
etap tests that depend on a working JS query server. Examples of these are 
tests which exercise validate_doc_update or other permissions related things. I 
suspect there are at least a few places the test suite touches JavaScript, even 
if it's not through the JS tests themselves.

If that issue is cleared up, I think this is probably easy.

> Build and configure without the js library
> --
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
>  Issue Type: New Feature
>  Components: Build System
> Environment: Any?
>Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will 
> not be accessing couch (nor do I want access) through an http interface, but 
> an erlang client library. 
> Thanks

--
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-1342) Asynchronous file writes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190584#comment-13190584
 ] 

Randall Leeds commented on COUCHDB-1342:


Bump! I made a branch on the central git repo so you all could iterate, not so 
I could kill the topic.
What's left to make everyone feel good about merging this?

> Asynchronous file writes
> 
>
> Key: COUCHDB-1342
> URL: https://issues.apache.org/jira/browse/COUCHDB-1342
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Reporter: Jan Lehnardt
> Fix For: 1.3
>
> Attachments: COUCHDB-1342.patch
>
>
> This change updates the file module so that it can do
> asynchronous writes. Basically it replies immediately
> to process asking to write something to the file, with
> the position where the chunks will be written to the
> file, while a dedicated child process keeps collecting
> chunks and write them to the file (and batching them
> when possible). After issuing a series of write request
> to the file module, the caller can call its 'flush'
> function which will block the caller until all the
> chunks it requested to write are effectively written
> to the file.
> This maximizes the IO subsystem, as for example, while
> the updater is traversing and modifying the btrees and
> doing CPU bound tasks, the writes are happening in
> parallel.
> Originally described at http://s.apache.org/TVu
> Github Commit: 
> https://github.com/fdmanana/couchdb/commit/e82a673f119b82dddf674ac2e6233cd78c123554

--
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-1206) View ETags may be incorrect if ?include_docs=true is specified

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189552#comment-13189552
 ] 

Randall Leeds commented on COUCHDB-1206:


I verified that the ?include_docs=true endpoint changes its ETag when a 
document is updated. It is of no importance whether or not the view with and 
without docs included have the same ETag as they are different URLs. Thanks for 
the concern, Marcello.

> View ETags may be incorrect if ?include_docs=true is specified
> --
>
> Key: COUCHDB-1206
> URL: https://issues.apache.org/jira/browse/COUCHDB-1206
> Project: CouchDB
>  Issue Type: Bug
>Affects Versions: 1.1
>Reporter: Jens Alfke
>Assignee: Robert Newson
>Priority: Minor
> Fix For: 1.1.1, 1.2
>
>
> Change COUCHDB-799 altered the way ETags are assigned to views, by having the 
> ETag change only when the view index changes, not when any document changes. 
> Unfortunately this means that a view with the "?include_docs=true" option can 
> return an incorrect ETag. The reason is that if a document in the view is 
> changed, but the change doesn't affect the view index, the result of the GET 
> will change (it will contain the document's updated contents), but the ETag 
> won't. This can result in stale data if the client uses a conditional GET, 
> because it'll get a 304 even though the prior response is out of date.
> Robert Newson's analysis on the user@ list is "I think the sanest fix is to 
> make view etags for include_docs=true use the original algorithm, so that 
> they always change if the database changes."

--
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-1304) set Expires header on session cookies to make them persistent

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189454#comment-13189454
 ] 

Randall Leeds commented on COUCHDB-1304:


Looks good. I'm fine for this to land on 1.2.

> set Expires header on session cookies to make them persistent
> -
>
> Key: COUCHDB-1304
> URL: https://issues.apache.org/jira/browse/COUCHDB-1304
> Project: CouchDB
>  Issue Type: Improvement
>  Components: HTTP Interface
>Affects Versions: 1.1
>Reporter: max ogden
>Assignee: Robert Newson
>Priority: Minor
>  Labels: authentication, cookie
> Fix For: 1.3
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> currently couch's cookie based authentication only sets session cookies as 
> opposed to persistent cookies. the difference between these two is the 
> Expires header. if it is not present most web browsers will delete your 
> cookie when you quit your browser, whereas if it is set then your browser 
> keeps the cookie around until the time specified by the Expires header.
> This sucks for UX because users quit and re-launch their browser they'll have 
> to log in again. 
> I am proposing that we set the Expires header in cookies to match the time in 
> the couch_httpd_auth timeout
> p.s. this is similar to the issue I opened 
> https://issues.apache.org/jira/browse/COUCHDB-1095 but at that time I didn't 
> realize that what I really wanted was the Expires header

--
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-1377) support X-Forwarded-* headers in couch_httpd

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182354#comment-13182354
 ] 

Randall Leeds commented on COUCHDB-1377:


Patch which honors all the options.

> support X-Forwarded-* headers in couch_httpd
> 
>
> Key: COUCHDB-1377
> URL: https://issues.apache.org/jira/browse/COUCHDB-1377
> Project: CouchDB
>  Issue Type: Improvement
>  Components: HTTP Interface
>Affects Versions: 1.1.1, 1.2
>Reporter: Randall Leeds
>Assignee: Randall Leeds
> Fix For: 1.2.1, 1.3
>
> Attachments: 
> v1-0001-COUCHDB-1377-X-Forwarded-headers-in-proxy-module.patch
>
>
> X-Forwarded-For, as well as X-Forwarded-Proto and X-Forwarded-Ssl, are 
> partially supported by the couch_httpd module. However, the couch_httpd_proxy 
> module ignores these same configuration settings when it could manipulate the 
> headers to pass more information upstream.

--
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-1371) configure erroneously warns against using a new spidermonkey with old spidermonkeys

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176280#comment-13176280
 ] 

Randall Leeds commented on COUCHDB-1371:


I hope there does come a time when we drop support.

How's this configure.ac patch? I can apply it and fix the INSTALL files if 
you'd like.

> configure erroneously warns against using a new spidermonkey with old 
> spidermonkeys
> ---
>
> Key: COUCHDB-1371
> URL: https://issues.apache.org/jira/browse/COUCHDB-1371
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Randall Leeds
>Assignee: Randall Leeds
>Priority: Minor
> Fix For: 1.2, 1.3, 1.1.2
>
> Attachments: 0001-fix-bad-configure-warning-on-old-SpiderMonkey.patch
>
>
> Paul added the check for JSOPTION_ANONFUNFIX in 7ce9e103e, but js-1.7 doesn't 
> have this constant so configure gives a warning.

--
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-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175892#comment-13175892
 ] 

Randall Leeds commented on COUCHDB-1367:


> Wait a second. Robert, you are not fixing a bug in C-L, you are working 
> around a deficiency in CouchDB.

Can't both be true?

> The only way to know the latest sequence id is to make a complete _changes 
> query. Next, follow that up with a continuous feed if you want to keep the 
> state fresh.

Nope. You can not ever know. You always know the latest sequence number at some 
arbitrarily recent point in time. If the (possibly continuous) changes feed 
says you're at X and you haven't heard anything more yet, then the database is 
at update sequence >= X. Neveretheless, I think I follow the sentiment. If 
last_seq were there one could know from an info request whether or not more 
changes should be available.

> What if I want to see the most recent five changes? What if there are a 
> hundred million documents? What if 99% of the time, update_seq equals 
> last_seq and so developers assume it means something it doesn't?

In order:
 * /_changes?descending=true&limit=5
 * Not sure how this is relevant
 * This does indeed seem to cause some confusion. It clearly surprised Robert 
and Henrik and it's the first I've heard of this discrepancy.

I submit that this bug is closed accurately with a suggestion to move proposals 
to improve the situation over to the dev list. Off the top of my head a partial 
list of suggestions goes something like:
 * Add additional information to the changes feed, perhaps with a query 
parameter (almost the reverse of include docs)
 * Stop incrementing the update sequence on certain kinds of non-document 
changes
 * Add more information to the db information response

Please take it from there and we can work through a proposal. Thanks, everyone.

> When settings revs_limit on db - the db increases its update_seq counter when 
> viewing stats - but not when getting changes
> --
>
> Key: COUCHDB-1367
> URL: https://issues.apache.org/jira/browse/COUCHDB-1367
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Any
>Reporter: Henrik Hofmeister
>Priority: Minor
>  Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the 
> http://host/dbname/ info document gets an increase in update_seq number - 
> however the changes feed does not contain this change (while its not a 
> change). This causes the update_seq in the dbinfo doc and the last seq in the 
> changes feed to differ - which breaks any application depending on the 
> update_seq number as the expected sequence size of the db (in my case - 
> couchdb-lucene that will only respond to stale requests because it thinks its 
> not up to date)
> I know this is an edge case - but still its something fairly fundamental - 
> that clearly is not working as intended. 

--
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-1371) configure erroneously warns against using a new spidermonkey with old spidermonkeys

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175834#comment-13175834
 ] 

Randall Leeds commented on COUCHDB-1371:


I think I forgot an "anyway".

> configure erroneously warns against using a new spidermonkey with old 
> spidermonkeys
> ---
>
> Key: COUCHDB-1371
> URL: https://issues.apache.org/jira/browse/COUCHDB-1371
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Randall Leeds
>Assignee: Randall Leeds
>Priority: Minor
> Fix For: 1.2, 1.3, 1.1.2
>
> Attachments: 0001-fix-bad-configure-warning-on-old-SpiderMonkey.patch
>
>
> Paul added the check for JSOPTION_ANONFUNFIX in 7ce9e103e, but js-1.7 doesn't 
> have this constant so configure gives a warning.

--
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-1371) configure erroneously warns against using a new spidermonkey with old spidermonkeys

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175833#comment-13175833
 ] 

Randall Leeds commented on COUCHDB-1371:


It's true: we have it and it works. However, it is significant testing burden 
in support of something that was released years ago. I'd even pull for dropping 
everything but 1.8.5 on versions of CouchDB that were released after 1.8.5 came 
out, but welcome arguments against it. I'm making significant patches to this 
stuff and it's less than fun to have to test it against three very similar 
versions of SpiderMonkey.

The way I see it there is one good argument for keeping old support: users 
building from source might have the dependency already.
Packagers don't suffer because they often don't update major versions of 
CouchDB between releases anyway and Firefox drives them to get new 
mozilla-central upstream sources periodically anyway. If we make good on all 
the discussion we've had about packaging then we could be solving this for a 
lot of users ourselves anyway. It feels silly for us to triple our testing 
burden to support users that want to compile a shiny new release of CouchDB 
with a three year old SpiderMonkey embedding. End rant.

> configure erroneously warns against using a new spidermonkey with old 
> spidermonkeys
> ---
>
> Key: COUCHDB-1371
> URL: https://issues.apache.org/jira/browse/COUCHDB-1371
> Project: CouchDB
>  Issue Type: Bug
>Reporter: Randall Leeds
>Assignee: Randall Leeds
>Priority: Minor
> Fix For: 1.2, 1.3, 1.1.2
>
> Attachments: 0001-fix-bad-configure-warning-on-old-SpiderMonkey.patch
>
>
> Paul added the check for JSOPTION_ANONFUNFIX in 7ce9e103e, but js-1.7 doesn't 
> have this constant so configure gives a warning.

--
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-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175262#comment-13175262
 ] 

Randall Leeds commented on COUCHDB-1367:


For _revs_limit we could always surface a change to the document with id 
"_revs_limit", which is _somewhat_ accurate (though it's not a full doc with 
revisions). Similar thoughts apply for _security.

If there's no technical reason why we need to bump the seq for changes that 
don't modify a document we could just stop doing that. What operations do this 
currently? How many of these resources have we at one time or another discussed 
making into a full document?

> When settings revs_limit on db - the db increases its update_seq counter when 
> viewing stats - but not when getting changes
> --
>
> Key: COUCHDB-1367
> URL: https://issues.apache.org/jira/browse/COUCHDB-1367
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Any
>Reporter: Henrik Hofmeister
>Assignee: Bob Dionne
>Priority: Minor
>  Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the 
> http://host/dbname/ info document gets an increase in update_seq number - 
> however the changes feed does not contain this change (while its not a 
> change). This causes the update_seq in the dbinfo doc and the last seq in the 
> changes feed to differ - which breaks any application depending on the 
> update_seq number as the expected sequence size of the db (in my case - 
> couchdb-lucene that will only respond to stale requests because it thinks its 
> not up to date)
> I know this is an edge case - but still its something fairly fundamental - 
> that clearly is not working as intended. 

--
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-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175228#comment-13175228
 ] 

Randall Leeds commented on COUCHDB-1367:


I suggested the heartbeat because we could make it look like last_seq, but we 
don't even need to use heartbeat. We could emit a change that doesn't have a 
corresponding id and revisions. Although, since the URL is /db/_revs_limit, we 
could (to use that example) emit something like:

{"seq":X,"id":"_revs_limit","changes":[]}

I have no idea how badly that confuse existing clients, including CouchDB. 
Putting it on the db info is the least obtrusive from an API standpoint. From a 
code internals, I think everything would require some change (with the 
exception of doing nothing about this). I'm going to step away for now, but if 
you need any more color swatches I can send over some more samples.

> When settings revs_limit on db - the db increases its update_seq counter when 
> viewing stats - but not when getting changes
> --
>
> Key: COUCHDB-1367
> URL: https://issues.apache.org/jira/browse/COUCHDB-1367
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Any
>Reporter: Henrik Hofmeister
>Assignee: Bob Dionne
>Priority: Minor
>  Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the 
> http://host/dbname/ info document gets an increase in update_seq number - 
> however the changes feed does not contain this change (while its not a 
> change). This causes the update_seq in the dbinfo doc and the last seq in the 
> changes feed to differ - which breaks any application depending on the 
> update_seq number as the expected sequence size of the db (in my case - 
> couchdb-lucene that will only respond to stale requests because it thinks its 
> not up to date)
> I know this is an edge case - but still its something fairly fundamental - 
> that clearly is not working as intended. 

--
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-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175217#comment-13175217
 ] 

Randall Leeds commented on COUCHDB-1367:


My gut says it's more confusing to put update_seq and last_seq in the db info. 
If clients want to be sure they're up to date, they need only pass a heartbeat 
parameter to the changes feed. If the heartbeats are coming in but no updates 
are, the feed is up to date.

> When settings revs_limit on db - the db increases its update_seq counter when 
> viewing stats - but not when getting changes
> --
>
> Key: COUCHDB-1367
> URL: https://issues.apache.org/jira/browse/COUCHDB-1367
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Any
>Reporter: Henrik Hofmeister
>Assignee: Bob Dionne
>Priority: Minor
>  Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the 
> http://host/dbname/ info document gets an increase in update_seq number - 
> however the changes feed does not contain this change (while its not a 
> change). This causes the update_seq in the dbinfo doc and the last seq in the 
> changes feed to differ - which breaks any application depending on the 
> update_seq number as the expected sequence size of the db (in my case - 
> couchdb-lucene that will only respond to stale requests because it thinks its 
> not up to date)
> I know this is an edge case - but still its something fairly fundamental - 
> that clearly is not working as intended. 

--
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-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175162#comment-13175162
 ] 

Randall Leeds commented on COUCHDB-1367:


I'd propose making the heartbeat option send the last_seq row, but that'd 
probably break clients that expect a disconnect at that point.

> When settings revs_limit on db - the db increases its update_seq counter when 
> viewing stats - but not when getting changes
> --
>
> Key: COUCHDB-1367
> URL: https://issues.apache.org/jira/browse/COUCHDB-1367
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Any
>Reporter: Henrik Hofmeister
>Assignee: Bob Dionne
>Priority: Minor
>  Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the 
> http://host/dbname/ info document gets an increase in update_seq number - 
> however the changes feed does not contain this change (while its not a 
> change). This causes the update_seq in the dbinfo doc and the last seq in the 
> changes feed to differ - which breaks any application depending on the 
> update_seq number as the expected sequence size of the db (in my case - 
> couchdb-lucene that will only respond to stale requests because it thinks its 
> not up to date)
> I know this is an edge case - but still its something fairly fundamental - 
> that clearly is not working as intended. 

--
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-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175160#comment-13175160
 ] 

Randall Leeds commented on COUCHDB-1367:


Oh, I messed up. Monotonic does not mean what I think it means. I meant it need 
not increase by intervals of 1 all the time.

> When settings revs_limit on db - the db increases its update_seq counter when 
> viewing stats - but not when getting changes
> --
>
> Key: COUCHDB-1367
> URL: https://issues.apache.org/jira/browse/COUCHDB-1367
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Any
>Reporter: Henrik Hofmeister
>Assignee: Bob Dionne
>Priority: Minor
>  Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the 
> http://host/dbname/ info document gets an increase in update_seq number - 
> however the changes feed does not contain this change (while its not a 
> change). This causes the update_seq in the dbinfo doc and the last seq in the 
> changes feed to differ - which breaks any application depending on the 
> update_seq number as the expected sequence size of the db (in my case - 
> couchdb-lucene that will only respond to stale requests because it thinks its 
> not up to date)
> I know this is an edge case - but still its something fairly fundamental - 
> that clearly is not working as intended. 

--
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-1090) jquery.couch.js enforces cache option

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175141#comment-13175141
 ] 

Randall Leeds commented on COUCHDB-1090:


Sorry to chime in late, but I don't think you should shy away from removing 
that line.

> jquery.couch.js enforces cache option
> -
>
> Key: COUCHDB-1090
> URL: https://issues.apache.org/jira/browse/COUCHDB-1090
> Project: CouchDB
>  Issue Type: Bug
>  Components: Infrastructure
>Reporter: Dale Harvey
>Priority: Trivial
> Attachments: cache.patch
>
>
> jquery.couch.js explicitly sets a cache, preventing the programmer from being 
> able to set it

--
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-1367) When settings revs_limit on db - the db increases its update_seq counter when viewing stats - but not when getting changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175136#comment-13175136
 ] 

Randall Leeds commented on COUCHDB-1367:


I'm confused about why a client listening to continuous _changes should care 
whether or not update_seq changes without emitting a document modification. I 
like to think that in the future other sorts of changes might be allowed to 
surface in that feed. Is there any place we guarantee that seq in the changes 
feed should be monotonic? I don't think so. It seems to me like this is not a 
problem.

> When settings revs_limit on db - the db increases its update_seq counter when 
> viewing stats - but not when getting changes
> --
>
> Key: COUCHDB-1367
> URL: https://issues.apache.org/jira/browse/COUCHDB-1367
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1.1
> Environment: Any
>Reporter: Henrik Hofmeister
>Assignee: Bob Dionne
>Priority: Minor
>  Labels: revs_limit
>
> If you put a number to _revs_limit on a db (to update it) - the 
> http://host/dbname/ info document gets an increase in update_seq number - 
> however the changes feed does not contain this change (while its not a 
> change). This causes the update_seq in the dbinfo doc and the last seq in the 
> changes feed to differ - which breaks any application depending on the 
> update_seq number as the expected sequence size of the db (in my case - 
> couchdb-lucene that will only respond to stale requests because it thinks its 
> not up to date)
> I know this is an edge case - but still its something fairly fundamental - 
> that clearly is not working as intended. 

--
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-1365) Fix merging of document with attachment stubs

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171942#comment-13171942
 ] 

Randall Leeds commented on COUCHDB-1365:


Right. I'm a space cadet. ERROR it is. Ship it.

> Fix merging of document with attachment stubs
> -
>
> Key: COUCHDB-1365
> URL: https://issues.apache.org/jira/browse/COUCHDB-1365
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core, Replication
>Reporter: Filipe Manana
>Priority: Blocker
> Fix For: 1.2, 1.1.2
>
> Attachments: 
> 0001-Fix-merging-of-documents-with-attachment-stubs.patch, 
> 0001-Fix-merging-of-documents-with-attachment-stubs.patch, 
> reproduce-CBMA-22.sh
>
>
> This issue was found by Marty Schoch and is reproducible the following 
> attached script.
> The commit message in the patch explains the issue:
> "During replicated updates, merging of documents with
> attachment stubs will fail if, after merging the received
> document's revision tree with the current on disk revision
> tree, produces a revision tree which doesn't contain the revision
> that immediately precedes the received document's revision.
> This happens when the received document doesn't contain in its
> revision history any of the revisions in the revision tree
> of the currently on disk document. This is possible when the
> document had a number of updates higher than the value of revs
> limit defined for the source database."

--
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-1365) Fix merging of document with attachment stubs

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171770#comment-13171770
 ] 

Randall Leeds commented on COUCHDB-1365:


+1. Mind if I lower the message about refetching in couch_replicator_worker 
(due to missing_stub) to WARN from ERROR?

> Fix merging of document with attachment stubs
> -
>
> Key: COUCHDB-1365
> URL: https://issues.apache.org/jira/browse/COUCHDB-1365
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core, Replication
>Reporter: Filipe Manana
>Priority: Blocker
> Fix For: 1.2, 1.1.2
>
> Attachments: 
> 0001-Fix-merging-of-documents-with-attachment-stubs.patch, 
> 0001-Fix-merging-of-documents-with-attachment-stubs.patch, 
> reproduce-CBMA-22.sh
>
>
> This issue was found by Marty Schoch and is reproducible the following 
> attached script.
> The commit message in the patch explains the issue:
> "During replicated updates, merging of documents with
> attachment stubs will fail if, after merging the received
> document's revision tree with the current on disk revision
> tree, produces a revision tree which doesn't contain the revision
> that immediately precedes the received document's revision.
> This happens when the received document doesn't contain in its
> revision history any of the revisions in the revision tree
> of the currently on disk document. This is possible when the
> document had a number of updates higher than the value of revs
> limit defined for the source database."

--
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-1363) Race condition edge case when pulling local changes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170547#comment-13170547
 ] 

Randall Leeds commented on COUCHDB-1363:


Thanks for the review. I'll explain more (I was distracted by talking after the 
CouchBase meetup).

I've run into this during the course of my work for COUCHDB-1350. As part of 
that, I had to change the replicator_db test and make the 
continuous_replication_survives_restart use bare db names instead of urls (the 
url changes after /_restart). I'm guessing I uncovered this race because the 
timing changes as a result of this different path.

In any case, unless I'm missing something fundamental it's most definitely a 
bug and this patch definitely fixes it. I tested by removing the line to stop 
CouchDB after the tests, so I could leave the replication running after the 
failure, which was line 700 of replicator_db.js. The replication stays open in 
active tasks but the fourth change, to doc 'foo1000', isn't replicated until I 
PUT another change to the source database. That is because the Db handle that's 
passed into handle_changes is pointing at an old header and the update_notifier 
hasn't been started yet. The patch re-opens the db after subscribing to 
notifications, which ensures we can't miss an update and stall in this way.

It probably doesn't bite many people, though (replication starts again as soon 
as the next change comes), but I can think of situations I've seen where this 
could be a problem.

Thanks for catching the shadowing issue. I didn't notice the warning when I 
compiled. I thought that the DbName in the fun header would be matched against 
the DbName in the handle_changes header instead of shadowing. My intention was 
not to change that functionality and I should probably have left it alone.

Let me know if it's okay to commit (- the shadowing). I don't see a better fix. 
Do you?

> Race condition edge case when pulling local changes
> ---
>
> Key: COUCHDB-1363
> URL: https://issues.apache.org/jira/browse/COUCHDB-1363
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 1.0.3, 1.1.1
>Reporter: Randall Leeds
>Assignee: Filipe Manana
>Priority: Minor
> Fix For: 1.2, 1.3
>
> Attachments: 0001-Fix-a-race-condition-starting-replications.patch
>
>
> It's necessary to re-open the #db after subscribing to notifications so that 
> updates are not lost. In practice, this is rarely problematic because the 
> next change will cause everything to catch up, but if a quick burst of 
> changes happens while replication is starting the replication can go stale. 
> Detected by intermittent replicator_db js test failures.

--
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-1362) couchjs doesn't clean out global namespace between views calls

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167862#comment-13167862
 ] 

Randall Leeds commented on COUCHDB-1362:


Would sealing/freezing the global object be sufficient? Users could probably 
still hang stuff off attributes of the global object, such as passing 
information between views by adding it as a property of the log() function, but 
at that point users should _know_ they're being tricky and they might get 
punched.

With SM1.8.5 we could deep freeze the object, though I'd have to double check 
that it wouldn't break any functionality.

> couchjs doesn't clean out global namespace between views calls
> --
>
> Key: COUCHDB-1362
> URL: https://issues.apache.org/jira/browse/COUCHDB-1362
> Project: CouchDB
>  Issue Type: Bug
>Affects Versions: 1.1.1
> Environment: Linux
>Reporter: jay groven
>Priority: Minor
>
> Sometimes a view can access the functions that were defined in a previous 
> view.  This can lead a developer to think that function sharing has been 
> implemented, but it's not reliable behaviour.  It would be better if the 
> global namespace were cleared between map/reduce runs so that it's clear that 
> there is no reliable way to share functions between views.

--
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-1320) OAuth authentication doesn't work with VHost entry

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167437#comment-13167437
 ] 

Randall Leeds commented on COUCHDB-1320:


Rather than rely on authenticate_request using the user_ctx that's already 
present and doing the trick you have committed, could we instead refactor 
couch_http to authenticate before the vhost dispatch and rewrite? Most of 
handle_request_int seems like it doesn't need to run again after a rewrite. 
Maybe it should have #http passed in and we could lift most of this up to 
handle_request. Then we don't have to fiddle with the user_ctx and we do less 
duplicate work after rewriting.

> OAuth authentication doesn't work with VHost entry
> --
>
> Key: COUCHDB-1320
> URL: https://issues.apache.org/jira/browse/COUCHDB-1320
> Project: CouchDB
>  Issue Type: Bug
>  Components: HTTP Interface
>Affects Versions: 1.1
> Environment: Ubuntu
>Reporter: Martin Higham
>Assignee: Filipe Manana
> Fix For: 1.2
>
> Attachments: Fix-OAuth-that-broke-with-vhost.patch, 
> fdmanana-0001-Fix-OAuth-authentication-with-VHosts-URL-rewriting.patch
>
>
> If you have a vhost entry that modifies the path (such as my host.com = 
> /mainDB/_design/main/_rewrite ) trying to authenticate a request to this host 
> using OAuth fails.
> couch_httpd_oauth uses the modified path rather than the original 
> x-couchdb-vhost-path when calculating the signature.

--
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-1357) Authentication failure after updating password in user document

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164121#comment-13164121
 ] 

Randall Leeds commented on COUCHDB-1357:


Patch looks good.

> Authentication failure after updating password in user document
> ---
>
> Key: COUCHDB-1357
> URL: https://issues.apache.org/jira/browse/COUCHDB-1357
> Project: CouchDB
>  Issue Type: Bug
>Affects Versions: 1.1.1
>Reporter: Filipe Manana
> Attachments: COUCHDB-1357-master.patch
>
>
> From the report at the users mailing list:
> http://s.apache.org/9OG
> Seems like after updating the password in a user doc, the user is not able to 
> login with the new password unless Couch is restarted. Sounds like a caching 
> issue.
> The only case of getting the cache consistent with the _users database 
> content is if the _users database processes crash and after the crash user 
> documents are updated. The cache daemon is ignoring the database crash.
> The following patch updates the daemon to monitor the _users database and 
> crash (letting the supervisor restart it) if the database process crashes.
> Etap test included.
> This might be related to COUCHDB-1212.

--
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-1323) couch_replicator

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162527#comment-13162527
 ] 

Randall Leeds commented on COUCHDB-1323:


Is there any reason not to ignore .* everywhere in the project instead?
For example, I often blow away my .emacs (custom couchdb dev settings) and 
.emacs.deskop files doing a clean.
Do we have any .* files that are legitimately included (aside from .gitignore)?

A quick look (find . -iname ".*") doesn't show anything outside .git (aside 
from .gitignore) that's actually checked in.

> couch_replicator
> 
>
> Key: COUCHDB-1323
> URL: https://issues.apache.org/jira/browse/COUCHDB-1323
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0, 1.3
>Reporter: Benoit Chesneau
>  Labels: replication
> Attachments: 0001-create-couch_replicator-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0002-refactor-couch_replicator.patch, 0002-refactor-couch_replicator.patch
>
>
> patch to move couch replication modules in in a standalone couch_replicator 
> application. It's also available on my github:
> https://github.com/benoitc/couchdb/compare/master...couch_replicator

--
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-1323) couch_replicator

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13162472#comment-13162472
 ] 

Randall Leeds commented on COUCHDB-1323:


Thanks, Benoit. Indentation in couch_replicator.app.src is inconsistent, but 
otherwise everything looks good. +1.

> couch_replicator
> 
>
> Key: COUCHDB-1323
> URL: https://issues.apache.org/jira/browse/COUCHDB-1323
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Replication
>Affects Versions: 2.0, 1.3
>Reporter: Benoit Chesneau
>  Labels: replication
> Attachments: 0001-create-couch_replicator-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0001-move-couchdb-replication-to-a-standalone-application.patch, 
> 0002-refactor-couch_replicator.patch
>
>
> patch to move couch replication modules in in a standalone couch_replicator 
> application. It's also available on my github:
> https://github.com/benoitc/couchdb/compare/master...couch_replicator

--
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-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158243#comment-13158243
 ] 

Randall Leeds commented on COUCHDB-431:
---

I noticed that the Requirements appendix, item 11 states that cors policies for 
resources on the same origin may differ.

"11. It should be possible to configure distinct cross-origin authorization 
policies for different target resources that reside within the same origin." - 
(http://www.w3.org/TR/cors/#requirements)

This contradicts my past assumption. It invalidates my Max-Age suggestions. 
Also, it improves the use case for _security level config. I'll try to update 
the unit tests with my last comment and we can keep iterating.

Jason and I also discussed some possibilities for configuration at host level 
which sounded reasonable. However, maybe we should consider another 
possibility. I will take it to the mailing list.

> 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

[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158238#comment-13158238
 ] 

Randall Leeds commented on COUCHDB-431:
---

CORS by default is too scary with local DBs. I think it breaks common 
assumptions about the web. I don't want to have to create admin accounts on my 
local, 127.0.0.1 couch in order to prevent a malicious site from stealing my 
personal data.

As for credentials for all origins, I'm saying that the spec asks browsers not 
to allow it, therefore whatever config system we have need not allow that to be 
configured.
For example, Jason suggested something like:
[cors]
hostA = http://originX https://originY
hostB = *

Where default would be to allow credentials for originX and originY, but not 
for any other. Without specifying credentials in the ini file, the default is 
to do what the spec says are the use cases.

I still think we can do better for configuration, though.

> 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

[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158221#comment-13158221
 ] 

Randall Leeds commented on COUCHDB-431:
---

Jason and I talked at (great) length today (thanks again, Jason). Here are the 
important conclusions.

- Default CORS policy MUST be to deny requests. In particular, this is to 
prevent breaking the assumption that a local couch is secure by virtue of not 
facing the public Internet. Since an attacker can cause a CORS request to 
127.0.0.1, it is dangerous to enable CORS by default (even if the methods are 
restricted and credentials are stripped).

- Default should be Access-Control-Allow-Credentials: false. Even when CORS is 
turned on, credentials should be disabled unless specifically enabled.

- The specification instructs (6.2#2 - 6.2#3) clients to abort requests when 
Access-Control-Allow-Origin is "*" and Access-Control-Allow-Credentials is not 
"false". Therefore, our implementation should not allow an administrator to 
configure this combination of settings.

> 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

[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13158035#comment-13158035
 ] 

Randall Leeds commented on COUCHDB-431:
---

@benoitc since the CouchDB is a single server, every host configured is a 
virtual host, or vhost. Sorry if that was confusing.

My issue with _security level config is that we cannot guarantee, in general, 
that all resources on a single host will have the same cors headers. This is 
broken as per the spec ("only cross-origin security is provided and that 
therefore using a distinct origin rather than distinct path is vital for secure 
client-side Web applications."). I find the spec confusing, because I'm not 
sure what the implication is for client-side Web-application authors. It seems 
to me like this applies more to servers than clients.

What I said about the cache didn't make sense, especially since simple requests 
can bypass the cache. Supporting a configurable max-age is extra and does not 
affect critical behaviours.

I don't think secure_rewrites make any difference. If we could limit _security 
cors settings to only apply when a host rule maps to a path under a database 
"A" we can ensure all paths under that host are subjected to the cors headers 
from the _security object of "A" even if some path (even "/") points to an 
insecure rewrite by applying the rules from the _security object of "A" no 
matter what db the rewritten path points to. I would feel good about this 
solution.

I'm starting to think that something like
[cors]
hostA = [{originX, none}, {originY, basic}]
hostB = [{originZ, including_admin}]

might be a reasonable approach.

If there is also a vhost like
[vhosts]
hostA = /dbA

then originX cannot make a CORS request to hostA even if dbA has a security 
object which allows it. However, originY is subject to whatever rules are in 
the security object of dbA with admin disabled.

On security and credentials:
I believe it is the responsibility of the CouchDB administrator to enable cors 
with credentials only for TLS-only hosts or the Web user to access a foreign 
Web application over a secure soceket (https->http CORS is disallowed by the 
spec) to ensure that cookies are not sent to CouchDB in the clear.

Any closer?

> 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

[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157897#comment-13157897
 ] 

Randall Leeds commented on COUCHDB-431:
---

After talking more about this today, it seems Benoit have sorted this out a bit 
more.
- We MUST not allow the preflight request cache to accidentally circumvent CORS 
settings for any path
- We SHOULD should both vhost-based configuration and db-level configuration

It's important to support both configurations. I reason that some dbs may want 
to allow any combination of read-only/read-write (don't forget to filter 
X-Request-Method!), anonymous/authenticated, and any set of headers; sometimes 
CouchDB is deployed without vhosts; server administrators MAY want to force 
CORS settings for a vhost despite any db settings. I don't see a clean way to 
fully support the options in the spec from a vhost/config-only approach. The 
security object is more flexible and unifies access control in one place.

After some consideration, I hope I have correctly determined that Jason's main 
fear with configuration via the _security object is that the invariant I listed 
first could be violated by a server which specifies, via _security objects on 
two or more databases, different access controls for two paths on the same 
origin. I would like to suggest that forcing the "Access-Control-Max-Age" 
header to "0" is sufficient to ensure good behaviour with _security objects 
specifying access control. Therefore, I'm working on a merge with unifies both 
patches and delegates to the db when nothing is set on the config level with 
these considerations in mind.

Finally, I think I want to do another couple of things as well before this is 
merged:
- For db-level configuration, it should be possible to customise Credentials, 
Method, and Headers.
- Default should be to deny all origins, both on the preflight and the final 
request. This applies to vhost-level configs, too.

How does this sit with both of you? Give me your thoughts and I'll try to 
finish synthesising a merge when I wake up.

> 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 (XD

[jira] [Commented] (COUCHDB-431) Support cross domain XMLHttpRequest (XHR) calls by implementing Access Control spec

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13157634#comment-13157634
 ] 

Randall Leeds commented on COUCHDB-431:
---

I wanted to bump this discussion again so we can get this patch landed. I 
created the COUCHDB-431 branch on the project git repo and broke the tests out. 
The tests are committed now, which hopefully gives us a good target and stable 
base for applying alternative implementing patches.

Jason and Benoit: If there is consensus on an implementation, please tell me 
and I will commit it there. If not, please say so and I'll go back and review 
this again since they're not fresh in my mind.

> 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

[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only" mode)

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153978#comment-13153978
 ] 

Randall Leeds commented on COUCHDB-1287:


I'm pretty sure you two won't actually hold a grudge, but try to be more civil. 
I'd really rather outside observers not think we all hate each other in this 
community.

I've been super busy lately, or I'd offer a complete review myself. It sounds 
like you're close to reconciling your expectations, though, and that you may 
both be writing to the same feature. I agree with the approach of Benoit's 
patch more, though, re: the level at which authorisation is controlled.

Benoit, can you put it on a branch along with Jason's tests? I think if you can 
get your patch to pass his tests we'll be a lot closer to landing this.

> Inbox Database ("write-only" mode)
> --
>
> Key: COUCHDB-1287
> URL: https://issues.apache.org/jira/browse/COUCHDB-1287
> Project: CouchDB
>  Issue Type: New Feature
>  Components: HTTP Interface
>Affects Versions: 1.2
>Reporter: Jason Smith
>Priority: Minor
> Attachments: 
> 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch, 
> 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch, 
> A_0001-Refactor-reader_acl-test-functions-into-a-loop.patch, 
> A_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch, 
> A_0003-Allow-non-member-writes-if-_security.members.allow_a.patch, 
> B_0001-Refactor-reader_acl-test-functions-into-a-loop.patch, 
> B_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch, 
> B_0003-Allow-non-member-updates-if-_security.members.allow_.patch
>
>
> Currently, we can only grant combined read+write access in the _security 
> object "members" section. A user can either do both or neither. This prevents 
> a very common requirement for couch apps: sending private information from 
> less-privileged users to more-privileged users.
> There is no (reasonable) way to make an "inbox" where anybody may create a 
> doc for me, but only I may read it. An inbox database allows user-to-user, or 
> user-to-admin private messages. (Not only chat messages, but asynchronous 
> notifications--with a per-user inbox, perhaps even service requests and 
> responses.)
> There is no reason _security.members (formerly .readers) should control write 
> access. validate_doc_update() functions do this better.
> I propose a boolean flag, _security.members.allow_anonymous_writes. If it is 
> true, then CouchDB will allow document updates from non-members, giving 
> validate_doc_update() the final word on accepting or rejecting the update.
> Requirements:
> 1. Everything about _security stays the same (backward-compatible)
> 2. If members.allow_anonymous_writes === true, then most PUT and POSTs may 
> proceed
> 3. All updates are still subject to approval by all validate_doc_update 
> functions, same as before.
> These are the known changes to the security model. I consider these all to be 
> either very unlikely in practice, or worth the trade-off.
> * If you write to an inbox DB, you know, for a time, a subset of its 
> documents (but that's the point)
> * An _update function could reveal a document to the user, with or without 
> changing it. However, an admin must install such a misguided update function.
> * You can launch timing attacks to learn information about validate_doc_update
>   * You might discover whether doc IDs exist in the DB or not
>   * You might discover a well-known open source validation function. You can 
> look for bugs in its source code.
> * Zero or more things which Jason can't think of

--
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-1342) Asynchronous file writes

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13152729#comment-13152729
 ] 

Randall Leeds commented on COUCHDB-1342:


Ok. Wow.

I'm with Paul on these things: proc_lib and an exported loop function are a 
must.
I'm with Damien/Jason on these things: I fear a culture where things languish 
too much because we don't have it together, collectively, to iterate on things 
effectively.
I'm with Bob on this thing: I don't see why this can't sit on a branch where we 
can actually iterate and commit things _together_.

I stand alone in that: I made you all a branch. Guess what it's called!? 
COUCHDB-1342. Have at it!

> Asynchronous file writes
> 
>
> Key: COUCHDB-1342
> URL: https://issues.apache.org/jira/browse/COUCHDB-1342
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Reporter: Jan Lehnardt
> Fix For: 1.3
>
> Attachments: COUCHDB-1342.patch
>
>
> This change updates the file module so that it can do
> asynchronous writes. Basically it replies immediately
> to process asking to write something to the file, with
> the position where the chunks will be written to the
> file, while a dedicated child process keeps collecting
> chunks and write them to the file (and batching them
> when possible). After issuing a series of write request
> to the file module, the caller can call its 'flush'
> function which will block the caller until all the
> chunks it requested to write are effectively written
> to the file.
> This maximizes the IO subsystem, as for example, while
> the updater is traversing and modifying the btrees and
> doing CPU bound tasks, the writes are happening in
> parallel.
> Originally described at http://s.apache.org/TVu
> Github Commit: 
> https://github.com/fdmanana/couchdb/commit/e82a673f119b82dddf674ac2e6233cd78c123554

--
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-1334) Indexer speedup (for non-native view servers)

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13146413#comment-13146413
 ] 

Randall Leeds commented on COUCHDB-1334:


Then again, Adam, we've got the SpiderMonkey issues to take care of and we 
still need to figure out whether or not that changes 1.2 into 2.0 (unless maybe 
we have enough new stuff for 1.2 that we would just release a 
not-forward-compatible-with-SM-trunk major version anyway). We should 
collectively make a decision about what to do with these branches soon.

> Indexer speedup (for non-native view servers)
> -
>
> Key: COUCHDB-1334
> URL: https://issues.apache.org/jira/browse/COUCHDB-1334
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core, JavaScript View Server, View Server 
> Support
>Reporter: Filipe Manana
>Assignee: Filipe Manana
> Fix For: 1.2
>
> Attachments: 0001-More-efficient-view-updater-writes.patch, 
> 0002-More-efficient-communication-with-the-view-server.patch, 
> master-0002-More-efficient-communication-with-the-view-server.patch
>
>
> The following 2 patches significantly improve view index generation/update 
> time and reduce CPU consumption.
> The first patch makes the view updater's batching more efficient, by ensuring 
> each btree bulk insertion adds/removes a minimum of N (=100) key/value 
> pairts. This also makes the index file size grow not so fast with old data 
> (old btree nodes basically). This behaviour is already done in master/trunk 
> in the new indexer (by Paul Davis).
> The second patch maximizes the throughput with an external view server (such 
> as couchjs). Basically it makes the pipe (erlang port) communication between 
> the Erlang VM (couch_os_process basically) and the view server more efficient 
> since the 2 sides spend less time block on reading from the pipe.
> Here follow some benchmarks.
> test database at  http://fdmanana.iriscouch.com/test_db  (1 million documents)
> branch 1.2.x
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real  2m45.097s
> user  0m0.006s
> sys   0m0.007s
> view file size: 333Mb
> CPU usage:
> $ sar 1 60
> 22:27:20  %usr  %nice   %sys   %idle
> 22:27:21   38  0 12 50
> ()
> 22:28:21   39  0 13 49
> Average: 39  0 13 47   
> branch 1.2.x + batch patch (first patch)
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real  2m12.736s
> user  0m0.006s
> sys   0m0.005s
> view file size 72Mb
> branch 1.2.x + batch patch + os_process patch
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real  1m9.330s
> user  0m0.006s
> sys   0m0.004s
> view file size:  72Mb
> CPU usage:
> $ sar 1 60
> 22:22:55  %usr  %nice   %sys   %idle
> 22:23:53   22  0  6 72
> ()
> 22:23:55   22  0  6 72
> Average: 22  0  7 70   
> master/trunk
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real  1m57.296s
> user  0m0.006s
> sys   0m0.005s
> master/trunk + os_process patch
> $ echo 3 > /proc/sys/vm/drop_caches
> $ time curl http://localhost:5984/test_db/_design/test/_view/test1
> {"rows":[
> {"key":null,"value":100}
> ]}
> real  0m53.768s
> user  0m0.006s
> sys   0m0.006s

--
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-754) Improve couch_file write performance

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139501#comment-13139501
 ] 

Randall Leeds commented on COUCHDB-754:
---

Jan: We'd always love things to be faster and there's a lot of specific info in 
this ticket. I'd leave it open.

> Improve couch_file write performance
> 
>
> Key: COUCHDB-754
> URL: https://issues.apache.org/jira/browse/COUCHDB-754
> Project: CouchDB
>  Issue Type: Improvement
>Affects Versions: 1.0, 1.0.1
> Environment: some code might be platform-specific
>Reporter: Adam Kocoloski
> Attachments: cheaper-appending-v2.patch, cheaper-appending.patch
>
>
> I've got a number of possible enhancements to couch_file floating around in 
> my head, wanted to write them down.
> * Use fdatasync instead of fsync.  Filipe posted a patch to the OTP file 
> driver [1] that adds a new file:datasync/1 function.  I suspect that we won't 
> see much of a performance gain from this switch because we append to the file 
> and thus need to update the file metedata anyway.  On the other hand, I'm 
> fairly certain fdatasync is always safe for our needs, so if it is ever more 
> efficient we should use it.  Obviously, we'll need to fall back to 
> file:sync/1 on platforms where the datasync function is not available.
> * Use file:pwrite/2 to batch together multiple outstanding write requests.  
> This is essentially Paul's zip_server [2].  In order to take full advantage 
> of it we need to patch couch_btree to update nodes in parallel.  Currently 
> there should only be 1 outstanding write request in a couch_file at a time, 
> so it wouldn't help at all.
> * Open the file in append mode and stop seeking to eof in user space.  We 
> never modify files (aside from truncating, which is rare enough to be handled 
> separately), so perhaps it would help with performance if we let the kernel 
> deal with the seek.  We'd still need a way to get the file size for the 
> make_blocks function.  I'm wondering if file:read_file_info(Fd) is more 
> efficient than file:position(Fd, eof) for this purpose.
> A caveat - I'm not sure if append-only files are compatible with the previous 
> enhancement.  There is no file:write/2, and I have no idea how file:pwrite 
> behaves on a file which is opened append-only.  Is the Pos ignored, or is it 
> an error?  Will have to test.
> * Use O_DSYNC instead of fsync/fdatasync.  This one is inspired by antirez' 
> recent blog post [3] and some historical discussions on pgsql-performance.  
> Basically, it seems that opening a file with O_DSYNC (or O_SYNC on Linux, 
> which is currently the same thing) and doing all synchronous writes is 
> reasonably fast.  Antirez' tests showed 250 µs delays for (tiny) synchronous 
> writes, compared to 40 ms delays for fsync and fdatasync on his ext4 system.
> At the very least, this looks to be a compelling choice for file access when 
> the server is running with delayed_commits = true.  We'd need to patch the 
> OTP file driver again, and also investigate the cross-platform support.  In 
> particular, I don't think it works on NFS.
> [1]: http://github.com/fdmanana/otp/tree/fdatasync
> [2]: http://github.com/davisp/zip_server
> [3]: http://antirez.com/post/fsync-different-thread-useless.html

--
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-860) Futon appends wrong version number to files

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13132171#comment-13132171
 ] 

Randall Leeds commented on COUCHDB-860:
---

Not true. It asks that clients revalidate. The mochiweb_request:serve_file call 
we use provides the last-modified header from the file mtime. Clients 
interested in caching should provide if-modified-since and mochiweb will 
properly handles the 304 in this case: 
https://github.com/mochi/mochiweb/blob/master/src/mochiweb_request.erl#L598. I 
like that much more than having autotools generate all these files.

> Futon appends wrong version number to files
> ---
>
> Key: COUCHDB-860
> URL: https://issues.apache.org/jira/browse/COUCHDB-860
> Project: CouchDB
>  Issue Type: Bug
>  Components: Futon
>Affects Versions: 1.0.1
>Reporter: Volker Mische
>Assignee: Randall Leeds
>Priority: Minor
> Attachments: 
> 0001-remove-version-number-from-futon-static-resources.patch, 
> 0002-Futon-Cache-Control.patch
>
>
> Futon appends the CouchDB version number to the JavaScript files it loads. In 
> 1.0.1 it still appends 0.11

--
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-879) [PATCH] Replication fails due to {stream_to, {self(), once}} parameter

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131215#comment-13131215
 ] 

Randall Leeds commented on COUCHDB-879:
---

Is this still an issue with the new replicator?

> [PATCH] Replication fails due to {stream_to, {self(), once}} parameter
> --
>
> Key: COUCHDB-879
> URL: https://issues.apache.org/jira/browse/COUCHDB-879
> Project: CouchDB
>  Issue Type: Bug
>  Components: Replication
>Affects Versions: 1.0.1
> Environment: Linux midna 2.6.32.8-midna-2 #2 SMP Tue Feb 16 20:27:34 
> CET 2010 x86_64 GNU/Linux
>Reporter: Michael Stapelberg
> Attachments: couchdb-replication.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> When testing replication (with SSL and apache's mod_proxy, so you might need 
> the patch from #878) I noticed that erlang's ssl sometimes needs to send 
> multiple messages. However, due to the {stream_to, {self(), once}} option 
> when calling ibrowse, only the first message gets delivered (which includes 
> only the first chunk). When modifying the option to {stream_to, self()}, 
> replication works fine.
> Please thoroughly check the attached patch for side-effects (I'm not sure why 
> {self(), once} was used in the first place).

--
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-613) Compaction tasks crash

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13131211#comment-13131211
 ] 

Randall Leeds commented on COUCHDB-613:
---

Is this fixed with 1.1.1?

> Compaction tasks crash
> --
>
> Key: COUCHDB-613
> URL: https://issues.apache.org/jira/browse/COUCHDB-613
> Project: CouchDB
>  Issue Type: Bug
>  Components: Database Core
>Affects Versions: 0.11
> Environment: debian 5.0, amd64, couchdb from git.apache.org at 
> dd15c8ed5bf5873aec08a99a0687849f1d29f4c3
>Reporter: Robert Newson
>
> I'm running repeated tests where I create multiple databases on multiple 
> machines and then compact them all in parallel. 
> This almost always works but sometimes does not. Specifically, I have one 
> machine where each .compact file is about 50% complete (I know this because I 
> see successfully compacted versions of the same data on the other machines in 
> my set) and this in the log;
> [Mon, 04 Jan 2010 19:50:23 GMT] [error] [<0.17793.28>] Uncaught error in HTTP 
> request: {exit,noproc}
> [Mon, 04 Jan 2010 19:50:26 GMT] [error] [<0.17801.28>] Uncaught error in HTTP 
> request: {exit,noproc}
> [Mon, 04 Jan 2010 19:50:26 GMT] [error] [<0.17753.28>] Uncaught error in HTTP 
> request: {exit,noproc}
> I'm not sure it's related to the compact process crash but my http client 
> also received an error while polling _active_tasks for compaction to complete;
> Waiting for compaction to complete.
> Exception in thread "main" org.apache.http.conn.HttpHostConnectException: 
> Connection to http://machine_name:5984 refused

--
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-1302) Fix couchjs

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125637#comment-13125637
 ] 

Randall Leeds commented on COUCHDB-1302:


Tested 1.1.x with Paul's patches applied. I checked it against a few 
spidermonkey versions including debian unstable from the iceweasel package, 
ubuntu's xulrunner-1.9.2.17-dev and libmozjs185-dev. Verified that the 
configure throws an error on the new one. Didn't check spidermonkey trunk, but 
I trust that patch 0002 is fine. I say commit it for 1.1.x and we can start the 
release process, then open a new ticket to talk about what to do about 1.2.

Thanks, Paul!

> Fix couchjs
> ---
>
> Key: COUCHDB-1302
> URL: https://issues.apache.org/jira/browse/COUCHDB-1302
> Project: CouchDB
>  Issue Type: Improvement
>  Components: JavaScript View Server
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Paul Joseph Davis
>Priority: Blocker
> Attachments: 
> 0001-Prevent-linking-against-too-new-of-a-SpiderMonkey.patch, 
> 0002-Minor-fixes-to-link-agianst-SpiderMonkey-trunk.patch
>
>
> Figure out why some spidermonkeys have an error when doing: 
> eval("function(){}")

--
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-577) couchdb @ winxp: Simple RegExp's can not be executed

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125442#comment-13125442
 ] 

Randall Leeds commented on COUCHDB-577:
---

If you look in the Ubuntu changelog for that package, you can see that Chris 
Coulson applied downstream patches to CouchDB. The initial work to support the 
newer SpiderMonkey was based off his patches.

> couchdb @ winxp: Simple RegExp's can not be executed
> 
>
> Key: COUCHDB-577
> URL: https://issues.apache.org/jira/browse/COUCHDB-577
> Project: CouchDB
>  Issue Type: Bug
>  Components: JavaScript View Server
>Affects Versions: 0.10, 0.11
> Environment: WinXP, setup-couchdb-0.11.0b880589.exe, 
> setup-couchdb-0.10.0.exe
>Reporter: Thomas Mohaupt
>
> This show function failed on WinXP but pass on Linux:
> function (doc, req) {
>   var rr2 = new RegExp("\n");
>   rr2.exec("fafdadsds");
>   var rr = /\n/;
>   rr.exec("fafdadsds");
>   return "ok";
> }
> The first RegExp is ok, but the second one (simple form) can not be executed.
> 1> [debug] [<0.73.0>] 'GET' /c2/_design/dash/_show/overview {1,1}
> Headers: 
> [{'Accept',"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"},
>   {'Accept-Charset',"ISO-8859-1,utf-8;q=0.7,*;q=0.7"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"de-de,de;q=0.8,en-us;q=0.5,en;q=0.3"},
>   {'Cache-Control',"max-age=0"},
>   {'Connection',"keep-alive"},
>   {'Host',"127.0.0.1:5984"},
>   {'Keep-Alive',"300"},
>   {'User-Agent',"Mozilla/5.0 (Windows; U; Windows NT 5.1; de; 
> rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR
>  3.5.30729)"}]
> 1> [debug] [<0.73.0>] OAuth Params: []
> 1> [info] [<0.98.0>] OS Process :: function raised error: TypeError: rr.exec 
> is not a function
> 1> [info] [<0.98.0>] OS Process :: stacktrace: (null,[object Object])@:4
> runShow(function (doc, req) {var rr2 = new 
> RegExp("\n");rr2.exec("fafdadsds");var rr = /\n/;rr.exec("fafdadsds");return
> "ok";},null,[object Object],"function (doc, req) {\n  var rr2 = new 
> RegExp(\"\\n\");\n  rr2.exec(\"fafdadsds\");\n  var
> rr = /\\n/;\n  rr.exec(\"fafdadsds\");\n\n  return 
> \"ok\";\n}\n\n")@../share/couchdb/server/main.js:388
> ("function (doc, req) {\n  var rr2 = new RegExp(\"\\n\");\n  
> rr2.exec(\"fafdadsds\");\n  var rr = /\\n/;\n  rr.exec(\"fa
> fdadsds\");\n\n  return \"ok\";\n}\n\n",null,[object 
> Object])@../share/couchdb/server/main.js:358
> @../share/couchdb/server/main.js:842

--
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-577) couchdb @ winxp: Simple RegExp's can not be executed

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125279#comment-13125279
 ] 

Randall Leeds commented on COUCHDB-577:
---

CouchDB 1.1.1, which is currently being finalized, contains support for 1.8.5.

> couchdb @ winxp: Simple RegExp's can not be executed
> 
>
> Key: COUCHDB-577
> URL: https://issues.apache.org/jira/browse/COUCHDB-577
> Project: CouchDB
>  Issue Type: Bug
>  Components: JavaScript View Server
>Affects Versions: 0.10, 0.11
> Environment: WinXP, setup-couchdb-0.11.0b880589.exe, 
> setup-couchdb-0.10.0.exe
>Reporter: Thomas Mohaupt
>
> This show function failed on WinXP but pass on Linux:
> function (doc, req) {
>   var rr2 = new RegExp("\n");
>   rr2.exec("fafdadsds");
>   var rr = /\n/;
>   rr.exec("fafdadsds");
>   return "ok";
> }
> The first RegExp is ok, but the second one (simple form) can not be executed.
> 1> [debug] [<0.73.0>] 'GET' /c2/_design/dash/_show/overview {1,1}
> Headers: 
> [{'Accept',"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"},
>   {'Accept-Charset',"ISO-8859-1,utf-8;q=0.7,*;q=0.7"},
>   {'Accept-Encoding',"gzip,deflate"},
>   {'Accept-Language',"de-de,de;q=0.8,en-us;q=0.5,en;q=0.3"},
>   {'Cache-Control',"max-age=0"},
>   {'Connection',"keep-alive"},
>   {'Host',"127.0.0.1:5984"},
>   {'Keep-Alive',"300"},
>   {'User-Agent',"Mozilla/5.0 (Windows; U; Windows NT 5.1; de; 
> rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR
>  3.5.30729)"}]
> 1> [debug] [<0.73.0>] OAuth Params: []
> 1> [info] [<0.98.0>] OS Process :: function raised error: TypeError: rr.exec 
> is not a function
> 1> [info] [<0.98.0>] OS Process :: stacktrace: (null,[object Object])@:4
> runShow(function (doc, req) {var rr2 = new 
> RegExp("\n");rr2.exec("fafdadsds");var rr = /\n/;rr.exec("fafdadsds");return
> "ok";},null,[object Object],"function (doc, req) {\n  var rr2 = new 
> RegExp(\"\\n\");\n  rr2.exec(\"fafdadsds\");\n  var
> rr = /\\n/;\n  rr.exec(\"fafdadsds\");\n\n  return 
> \"ok\";\n}\n\n")@../share/couchdb/server/main.js:388
> ("function (doc, req) {\n  var rr2 = new RegExp(\"\\n\");\n  
> rr2.exec(\"fafdadsds\");\n  var rr = /\\n/;\n  rr.exec(\"fa
> fdadsds\");\n\n  return \"ok\";\n}\n\n",null,[object 
> Object])@../share/couchdb/server/main.js:358
> @../share/couchdb/server/main.js:842

--
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-1302) Fix couchjs

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124557#comment-13124557
 ] 

Randall Leeds commented on COUCHDB-1302:


Paul: +1 on both patches.

I might like Damjan's proposal. We should start that ticket for 1.2+.

> Fix couchjs
> ---
>
> Key: COUCHDB-1302
> URL: https://issues.apache.org/jira/browse/COUCHDB-1302
> Project: CouchDB
>  Issue Type: Improvement
>  Components: JavaScript View Server
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Paul Joseph Davis
>Priority: Blocker
> Attachments: 
> 0001-Prevent-linking-against-too-new-of-a-SpiderMonkey.patch, 
> 0002-Minor-fixes-to-link-agianst-SpiderMonkey-trunk.patch
>
>
> Figure out why some spidermonkeys have an error when doing: 
> eval("function(){}")

--
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-642) Support rev in PUT URL

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122491#comment-13122491
 ] 

Randall Leeds commented on COUCHDB-642:
---

Oh. I have this work already done. I'll double check that the preference 
ordering makes sense. I don't have any philosophical objection to allowing it 
in the URL and the way I've written it already asserts that if it's present in 
more than one place it has to match everywhere or it's a bad request.

> Support rev in PUT URL
> --
>
> Key: COUCHDB-642
> URL: https://issues.apache.org/jira/browse/COUCHDB-642
> Project: CouchDB
>  Issue Type: New Feature
>  Components: HTTP Interface
> Environment: trunk 08 Feb 2010
>Reporter: Brian Candler
>Priority: Minor
> Attachments: 0001-Allow-for-the-current-revision-number-to-be.patch
>
>
> A DELETE request lets you append ?rev= to the URL. But this doesn't work 
> with a PUT request; you have to put the _rev in the body instead (even though 
> the _id is taken from the URL path)
> $ curl -X PUT -d "{}" 
> http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
> {"ok":true,"id":"foo","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl -X PUT -d "{}" 
> http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo?rev=1-967a00dff5e02add41819138abb3284d
> {"error":"conflict","reason":"Document update conflict."}
> $ curl -X PUT -d '{"_rev":"1-967a00dff5e02add41819138abb3284d"}' 
> http://brianadmin:brianadmin@127.0.0.1:5984/briantest/foo
> {"ok":true,"id":"foo","rev":"2-7051cbe5c8faecd085a3fa619e6e6337"}
> Allowing ?rev in the URL would make PUT and DELETE more consistent, and would 
> allow you to replace an existing JSON doc with another one without having to 
> merge the _rev into it first.

--
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-1302) Fix couchjs

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122427#comment-13122427
 ] 

Randall Leeds commented on COUCHDB-1302:


+1 on 1 and 2.
+1 for 3. I'll write this up for 1.1.x if Paul doesn't beat me to it. 1.2/2.0 
needs something different though.

Paul discovered and mentioned in IRC that we can't actually look for the last 
function if people use named functions because eval('function map(...){...}') 
=== undefined. In other words, we need to pull 'map' out of the global scope 
after the call to eval() so it needs to have a well-known name.

So we're stuck opening up the 2.0 can of worms it seems. We should consider 
what the cleanest looking design document that makes this all look sane is and 
what effect any changes have on the way we index and optimize work for 
calculating design doc indexes.

We should focus on 1.1.1 and then open the bikeshed floodgates.

> Fix couchjs
> ---
>
> Key: COUCHDB-1302
> URL: https://issues.apache.org/jira/browse/COUCHDB-1302
> Project: CouchDB
>  Issue Type: Improvement
>  Components: JavaScript View Server
>Affects Versions: 1.1.1, 1.2, 1.3
>Reporter: Paul Joseph Davis
>Priority: Blocker
>
> Figure out why some spidermonkeys have an error when doing: 
> eval("function(){}")

--
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-1285) Allow configuration of vendor and module version in the welcome message

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119670#comment-13119670
 ] 

Randall Leeds commented on COUCHDB-1285:


I also would welcome a version where the module initialization hook returns a 
child specification so that it may be a supervisor or a worker and support the 
'dynamic' argument in the child specification.

Keep in mind that not every couchdb plugin/module needs to register anything 
under [modules]. Only if it needs to link into start/stop lifecycle hooks.

> Allow configuration of vendor and module version in the welcome message
> ---
>
> Key: COUCHDB-1285
> URL: https://issues.apache.org/jira/browse/COUCHDB-1285
> Project: CouchDB
>  Issue Type: Improvement
>Reporter: Jan Lehnardt
> Attachments: vendor_and_modules.patch, 
> vendor_and_modules_objects.patch
>
>
> The patch below allows to configure vendor and module version information 
> into the GET / welcome message.
> E.g.
>   [vendor]
>   name = refuge
>   version = 2.0.0
>   
>   [modules]
>   geocouch = 1.2.1
> would produce:
>   
> {"couchdb":"Welcome","version":"1.2.0","refuge":"2.0.0","modules":{"geocouch":"1.2.1"}}
> --
> --- a/src/couchdb/couch_httpd_misc_handlers.erl
> +++ b/src/couchdb/couch_httpd_misc_handlers.erl
> @@ -30,9 +30,23 @@
>  % httpd global handlers
>  
>  handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) ->
> +Vendor = case couch_config:get("vendor") of
> +  [] -> [];
> +  Vendor1 -> [{
> +proplists:get_value("name", Vendor1),
> +?l2b(proplists:get_value("version", Vendor1))
> +  }]
> +end,
> +
> +Modules = lists:map(fun({Key, Value}) ->
> +  {Key, ?l2b(Value)}
> +end, couch_config:get("modules")),
> +
>  send_json(Req, {[
>  {couchdb, WelcomeMessage},
> -{version, list_to_binary(couch_server:get_version())}
> +{version, list_to_binary(couch_server:get_version())}]
> +++ Vendor
> +++ [{modules, {Modules}}
>  ]});
>  handle_welcome_req(Req, _) ->
>  send_method_not_allowed(Req, "GET,HEAD").
> -- 

--
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-1285) Allow configuration of vendor and module version in the welcome message

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119074#comment-13119074
 ] 

Randall Leeds commented on COUCHDB-1285:


Did you mean:
vendors: {"vendorname": { "version": ...}, ...} ?

vendors is an object of vendorname : attribute object rather than an array?

> Allow configuration of vendor and module version in the welcome message
> ---
>
> Key: COUCHDB-1285
> URL: https://issues.apache.org/jira/browse/COUCHDB-1285
> Project: CouchDB
>  Issue Type: Improvement
>Reporter: Jan Lehnardt
> Attachments: vendor_and_modules_objects.patch
>
>
> The patch below allows to configure vendor and module version information 
> into the GET / welcome message.
> E.g.
>   [vendor]
>   name = refuge
>   version = 2.0.0
>   
>   [modules]
>   geocouch = 1.2.1
> would produce:
>   
> {"couchdb":"Welcome","version":"1.2.0","refuge":"2.0.0","modules":{"geocouch":"1.2.1"}}
> --
> --- a/src/couchdb/couch_httpd_misc_handlers.erl
> +++ b/src/couchdb/couch_httpd_misc_handlers.erl
> @@ -30,9 +30,23 @@
>  % httpd global handlers
>  
>  handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) ->
> +Vendor = case couch_config:get("vendor") of
> +  [] -> [];
> +  Vendor1 -> [{
> +proplists:get_value("name", Vendor1),
> +?l2b(proplists:get_value("version", Vendor1))
> +  }]
> +end,
> +
> +Modules = lists:map(fun({Key, Value}) ->
> +  {Key, ?l2b(Value)}
> +end, couch_config:get("modules")),
> +
>  send_json(Req, {[
>  {couchdb, WelcomeMessage},
> -{version, list_to_binary(couch_server:get_version())}
> +{version, list_to_binary(couch_server:get_version())}]
> +++ Vendor
> +++ [{modules, {Modules}}
>  ]});
>  handle_welcome_req(Req, _) ->
>  send_method_not_allowed(Req, "GET,HEAD").
> -- 

--
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-1298) X-Couch-Update-NewRev and "ETag" and Content-Type

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13117669#comment-13117669
 ] 

Randall Leeds commented on COUCHDB-1298:


I'm in favor of leaving X-Couch-Update-NewRev for update requests only to 
maintain compatibility until 2.0. That's on principle only, because I expect 
almost no one relies on it now. Still, I'll leave it.

I think it's okay to send back an ETag for PUT/POST, because maybe you want to 
do a conditional GET later.
I'm implementing all these fixes now and well as fixing some other tickets 
related to response codes and headers from _show/_list/_update.

> X-Couch-Update-NewRev and "ETag" and Content-Type
> -
>
> Key: COUCHDB-1298
> URL: https://issues.apache.org/jira/browse/COUCHDB-1298
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Affects Versions: 1.2
>Reporter: gert cuykens
>Assignee: Randall Leeds
>Priority: Trivial
>  Labels: couchdb
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> There are three inconsistencies 
> 1) The use of ETag vs X-Couch-Update-NewRev
> 2) The use of "..." around the rev number
> 3)  Content-Type: is different, see the space between ;...charset
> PUT /users/_design/user/_update/form/gert HTTP/1.1
> Host: 127.0.0.1:5984
> HTTP/1.1 201 Created
> X-Couch-Update-NewRev: 245-2ddebfc32429bc723cb20543a97d3598
> Server: CouchDB/1.3.0a-f07c75f-git (Erlang OTP/R13B03)
> Date: Wed, 28 Sep 2011 15:49:49 GMT
> Content-Type: text/html; charset=utf-8
> Content-Length: 8
> PUT /users/gert/picture.png HTTP/1.1
> Host: 127.0.0.1:5984
> HTTP/1.1 201 Created
> Server: CouchDB/1.3.0a-f07c75f-git (Erlang OTP/R13B03)
> Location: http://127.0.0.1:5984/users/gert/picture.png
> ETag: "246-f1291707f1827ef38217972ea1f3824c"
> Date: Wed, 28 Sep 2011 15:50:25 GMT
> Content-Type: text/plain;charset=utf-8
> Content-Length: 69
> Cache-Control: must-revalidate
> Pleas always use ETag without "..."
> When a new document is been created, also use ETag because its already 
> indicated by status 201, no need for special headers.
> Also note Content-Type: is different, see the space between ;...charset

--
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-1298) X-Couch-Update-NewRev and "ETag" and Content-Type

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116842#comment-13116842
 ] 

Randall Leeds commented on COUCHDB-1298:


I suspect X-Couch-Update-NewRev was added so that the revision could be 
returned even if the _update handler decides to provide its own ETag in the 
response and to leave the revision out of the response body. I will make the 
new revision the default ETag in the response headers for _update functions if 
the function author does not provide one explicitly. Thanks.

Note that a proper ETag should be surround by quotes, so that will not change: 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.19

> X-Couch-Update-NewRev and "ETag" and Content-Type
> -
>
> Key: COUCHDB-1298
> URL: https://issues.apache.org/jira/browse/COUCHDB-1298
> Project: CouchDB
>  Issue Type: Improvement
>  Components: Database Core
>Affects Versions: 1.2
>Reporter: gert cuykens
>Assignee: Randall Leeds
>Priority: Trivial
>  Labels: couchdb
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> There are two inconsistencies 
> 1) The use of ETag vs X-Couch-Update-NewRev
> 2) The use of "..." around the rev number
> PUT /users/_design/user/_update/form/gert HTTP/1.1
> Host: 127.0.0.1:5984
> HTTP/1.1 201 Created
> X-Couch-Update-NewRev: 245-2ddebfc32429bc723cb20543a97d3598
> Server: CouchDB/1.3.0a-f07c75f-git (Erlang OTP/R13B03)
> Date: Wed, 28 Sep 2011 15:49:49 GMT
> Content-Type: text/html; charset=utf-8
> Content-Length: 8
> PUT /users/gert/picture.png HTTP/1.1
> Host: 127.0.0.1:5984
> HTTP/1.1 201 Created
> Server: CouchDB/1.3.0a-f07c75f-git (Erlang OTP/R13B03)
> Location: http://127.0.0.1:5984/users/gert/picture.png
> ETag: "246-f1291707f1827ef38217972ea1f3824c"
> Date: Wed, 28 Sep 2011 15:50:25 GMT
> Content-Type: text/plain;charset=utf-8
> Content-Length: 69
> Cache-Control: must-revalidate
> Pleas always use ETag without "..."
> When a new document is been created, also use ETag because its already 
> indicated by status 201, no need for special headers.
> Also note Content-Type: is different, see the space between ;...charset

--
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-893) Error: os_process_error {exit_status,0} when rendering view on 17 mb doc, couchapp and data attached

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116828#comment-13116828
 ] 

Randall Leeds commented on COUCHDB-893:
---

Documented at http://wiki.apache.org/couchdb/Performance#JavaScript_View_Server

> Error: os_process_error  {exit_status,0}  when rendering view on 17 mb doc,  
> couchapp and data attached
> ---
>
> Key: COUCHDB-893
> URL: https://issues.apache.org/jira/browse/COUCHDB-893
> Project: CouchDB
>  Issue Type: Bug
>Affects Versions: 1.0.1
> Environment: I repeated this on windows and linux (64 bit)
>Reporter: Michael Schneider
>Assignee: Randall Leeds
> Fix For: 1.1.1, 1.2
>
> Attachments: bugdoc.tar.gz
>
>
> I have a large set of documents that  I harvesting data from.  All docs < 9mb 
> render fine (with doc size increased)
> Attached is a simple couchapp and one doc.
> To reproduce, untar and:
>  reproduce
> 1)  untar file
> 2) cd bugdoc/couchapp/bugreport
> 3) couchapp push bugreport
> 4) cd bugdoc
> 5) python submitbadjson.py
> open url 
> http://127.0.0.1:5984/_utils/database.html?bugreport/_design/bugreport/_view/buggy
> You should see a popup
> "(Error: os_process_error
> {exit_status,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

[jira] [Commented] (COUCHDB-752) InternalError: script stack space quota is exhausted

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116827#comment-13116827
 ] 

Randall Leeds commented on COUCHDB-752:
---

Documented at http://wiki.apache.org/couchdb/Performance#JavaScript_View_Server

> InternalError: script stack space quota is exhausted
> 
>
> Key: COUCHDB-752
> URL: https://issues.apache.org/jira/browse/COUCHDB-752
> Project: CouchDB
>  Issue Type: Bug
>  Components: JavaScript View Server
>Affects Versions: 0.11
>Reporter: Benoit Chesneau
>Assignee: Randall Leeds
>Priority: Critical
> Fix For: 1.1.1, 1.2
>
> Attachments: ddoc.patch
>
>
>  Couchdb freeze and use full CPU after accessing to  a 93MB designdoc:
> debug] [<0.91.0>] Spawning new group server for view group _design/aimpl in 
> database aimpl.
> [debug] [<0.94.0>] request_group {Pid, Seq} {<0.116.0>,61}
> [debug] [<0.81.0>] New task status for aimpl _design/aimpl: Finishing.
> [debug] [<0.126.0>] OS Process Start :: #Port<0.2040>
> [debug] [<0.87.0>] Teach ddoc to new proc {proc,<0.126.0>,<<"javascript">>,[],
>  {couch_os_process,prompt},
>  {couch_os_process,set_timeout},
>  {couch_os_process,stop}} with DDocKey: 
> {<<"_design/aimpl">>,
>  
> <<"30-2ab623a62b83b0d9f2616ee209f62659">>}
> InternalError: script stack space quota is exhausted
> Most of data are in attachments :
> enlil:couchapp benoitc$ du -sh aimpl
>  93M  aimpl
> enlil:couchapp benoitc$ du -sh aimpl/_attachments/
>  93M  aimpl/_attachments/
> about 100k in views/shows/...

--
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-1293) Support in memory databases that can replicate

[Randall Leeds (Commented) (JIRA)]

[ 
https://issues.apache.org/jira/browse/COUCHDB-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13116812#comment-13116812
 ] 

Randall Leeds commented on COUCHDB-1293:


As a temporary work-around you could also mount a ram disk under your couch 
database directory and use encoded slashes in your DB name to put a DB under 
that storage. It would work, but would compaction would still be required for 
long-lived, heavily-updated DBs since nothing would change about the way couch 
sees the file.

> Support in memory databases that can replicate
> --
>
> Key: COUCHDB-1293
> URL: https://issues.apache.org/jira/browse/COUCHDB-1293
> Project: CouchDB
>  Issue Type: New Feature
>Reporter: Sam Bisbee
>
> The summary really says it all. It would be great if we could have databases 
> that live only in memory, but that could also be replicated to other URLs 
> (potentially a database on disk or another node in a cluster).
> I don't think views would be necessary for the sorts of things you'd be doing 
> all in memory (session data, temp data, etc.).
> I talked with Kocoloski about this around a month ago and it did not sound 
> like an easy feat because of the replication. I would still like to hear what 
> people have to say about it.

--
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