[jira] Commented: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759035#action_12759035 ] Benoit Chesneau commented on COUCHDB-512: - So you set acls in a global user db ? Wouldn't it be better if acl were set in the db rather than an external db ? So acls + users are replicated ? > Per-DB Authorization and ACL > > > Key: COUCHDB-512 > URL: https://issues.apache.org/jira/browse/COUCHDB-512 > Project: CouchDB > Issue Type: New Feature > Components: Database Core >Reporter: Jason Davies > Fix For: 0.10 > > Attachments: per_db_auth.patch > > > Following discussions on the mailing list, this is for tracking work and > comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CRLF or LF in our JSON?
Good find. \r\n FTW! On Wed, Sep 23, 2009 at 10:30 PM, Adam Kocoloski wrote: > Good idea. HTTP says CRLF everywhere except the entity-body, where it has > no comment. application/json couldn't care less what we do, but since we're > serving text/plain: > >> The canonical form of any MIME "text" subtype MUST always represent a >> line break as a CRLF sequence. Similarly, any occurrence of CRLF in >> MIME "text" MUST represent a line break. Use of CR and LF outside of >> line break sequences is also forbidden. > > > http://tools.ietf.org/html/rfc2046#section-4.1.1 > > That seems like a vote for CRLF across the board to me. Best, Adam > > On Sep 23, 2009, at 10:13 PM, Paul Davis wrote: > >> Is there a preference for text/plain or HTTP or somewhere we can >> default the decision to? It seems fairly arbitrary. >> >> I do remember someone saying just the other day that not having \r\n >> for changes meant that Twisted didn't work out of the box. I think it >> was Mark or Benoît. >> >> Paul >> >> On Wed, Sep 23, 2009 at 10:02 PM, Adam Kocoloski >> wrote: >>> >>> Hi, I noticed we're fairly inconsistent in the line terminators that we >>> use: >>> views use \r\n, _changes uses \n, etc. I guess we should standardize on >>> one >>> or the other. Anybody have a preference? Best, >>> >>> Adam >>> > >
Re: CRLF or LF in our JSON?
Good idea. HTTP says CRLF everywhere except the entity-body, where it has no comment. application/json couldn't care less what we do, but since we're serving text/plain: The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break. Use of CR and LF outside of line break sequences is also forbidden. http://tools.ietf.org/html/rfc2046#section-4.1.1 That seems like a vote for CRLF across the board to me. Best, Adam On Sep 23, 2009, at 10:13 PM, Paul Davis wrote: Is there a preference for text/plain or HTTP or somewhere we can default the decision to? It seems fairly arbitrary. I do remember someone saying just the other day that not having \r\n for changes meant that Twisted didn't work out of the box. I think it was Mark or Benoît. Paul On Wed, Sep 23, 2009 at 10:02 PM, Adam Kocoloski wrote: Hi, I noticed we're fairly inconsistent in the line terminators that we use: views use \r\n, _changes uses \n, etc. I guess we should standardize on one or the other. Anybody have a preference? Best, Adam
Re: CRLF or LF in our JSON?
Is there a preference for text/plain or HTTP or somewhere we can default the decision to? It seems fairly arbitrary. I do remember someone saying just the other day that not having \r\n for changes meant that Twisted didn't work out of the box. I think it was Mark or Benoît. Paul On Wed, Sep 23, 2009 at 10:02 PM, Adam Kocoloski wrote: > Hi, I noticed we're fairly inconsistent in the line terminators that we use: > views use \r\n, _changes uses \n, etc. I guess we should standardize on one > or the other. Anybody have a preference? Best, > > Adam >
CRLF or LF in our JSON?
Hi, I noticed we're fairly inconsistent in the line terminators that we use: views use \r\n, _changes uses \n, etc. I guess we should standardize on one or the other. Anybody have a preference? Best, Adam
[jira] Closed: (COUCHDB-470) Include peer in req object for lists, shows and updates
[ https://issues.apache.org/jira/browse/COUCHDB-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies closed COUCHDB-470. Resolution: Fixed Fixed in r818316. > Include peer in req object for lists, shows and updates > --- > > Key: COUCHDB-470 > URL: https://issues.apache.org/jira/browse/COUCHDB-470 > Project: CouchDB > Issue Type: Improvement >Reporter: Jason Davies > Attachments: couch_httpd_external.peer.patch > > > Simple one-liner. Useful for statistical tracking or any kind of IP-based > switching. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-512) Per-DB Authorization and ACL
[
https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Davies updated COUCHDB-512:
-
Attachment: per_db_auth.patch
Initial patch adding per-db auth using an ACL rule list defined in the
"_local/_acl" in the users db ("users" by default). We can look at extending
this and allow a similar document to exist per database too in the future. The
ACL document looks like:
{
"_id": "_local/_acl",
"rules": [
{"db": "*", "role": "*", "deny": "*"},
{"db": "*", "role": "test", "allow": "read"},
]
}
The last matching rule wins.
> Per-DB Authorization and ACL
>
>
> Key: COUCHDB-512
> URL: https://issues.apache.org/jira/browse/COUCHDB-512
> Project: CouchDB
> Issue Type: New Feature
> Components: Database Core
>Reporter: Jason Davies
> Fix For: 0.10
>
> Attachments: per_db_auth.patch
>
>
> Following discussions on the mailing list, this is for tracking work and
> comments surrounding an implementation of per-db authorization and ACL.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-512) Per-DB Authorization and ACL
Per-DB Authorization and ACL Key: COUCHDB-512 URL: https://issues.apache.org/jira/browse/COUCHDB-512 Project: CouchDB Issue Type: New Feature Reporter: Jason Davies Fix For: 0.10 Following discussions on the mailing list, this is for tracking work and comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-512) Per-DB Authorization and ACL
[ https://issues.apache.org/jira/browse/COUCHDB-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Davies updated COUCHDB-512: - Component/s: Database Core > Per-DB Authorization and ACL > > > Key: COUCHDB-512 > URL: https://issues.apache.org/jira/browse/COUCHDB-512 > Project: CouchDB > Issue Type: New Feature > Components: Database Core >Reporter: Jason Davies > Fix For: 0.10 > > > Following discussions on the mailing list, this is for tracking work and > comments surrounding an implementation of per-db authorization and ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-511) Revision referencing via something like Git's RefLog Shortnames
Revision referencing via something like Git's RefLog Shortnames --- Key: COUCHDB-511 URL: https://issues.apache.org/jira/browse/COUCHDB-511 Project: CouchDB Issue Type: Wish Components: HTTP Interface Reporter: Benjamin Young Priority: Minor Accessing earlier revisions isn't hard, but it would be very handy to reference them via a short hand notation similar to Git's RefLog Shortnames. Perhaps something very similar: http://localhost:5984/db/doc?rev=^ - this would get the previous revision http://localhost:5984/db/doc?rev=^3 - this would get the revision 3 submissions ago Just an idea. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-345) "High ASCII" can be inserted into db but not retrieved
[
https://issues.apache.org/jira/browse/COUCHDB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski closed COUCHDB-345.
--
Resolution: Fixed
Fix Version/s: 0.10
Assignee: Adam Kocoloski
Ok, I've committed the patch I wrote to trunk and the 0.10 release branch.
I'll submit it upstream to the Mochi team as well. We still need to address
the issue of alternate encodings and Content-Encoding headers so we don't come
across as "lazy and inconsiderate" :)
> "High ASCII" can be inserted into db but not retrieved
> --
>
> Key: COUCHDB-345
> URL: https://issues.apache.org/jira/browse/COUCHDB-345
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: OSX 10.5.6
>Reporter: Joan Touzet
>Assignee: Adam Kocoloski
> Fix For: 0.10
>
> Attachments: badenc1.patch, badtext.tar.gz, enctest.zip,
> reject_invalid_utf8.patch
>
>
> It is possible to PUT/POST a document into CouchDB with a "high ASCII" value
> that cannot be retrieved. This results from not escaping a non-ASCII value
> into \u when PUT/POSTing the document.
> The attached sample code will recreate the problem using the hex value D8 (Ø)
> in a possibly unsavoury test string.
> Sample output against 0.9.0 is as follows:
>
> {
> "ok": true
> }
> {
> "id": "fail",
> "ok": true,
> "rev": "1-76726372"
> }
> {
> "error": "ucs",
> "reason": "{bad_utf8_character_code}"
> }
>
> Please note this defect turned up another problem, namely that the
> bad_utf8_character_code exception thrown by a design document attempting to
> map() the bad document caused Futon to fail silently in building the view,
> with no indication (except via debug log) that there was a failure. The log
> indicated two attempts to build the view, both failing, followed by an
> uncaught exception error for Futon.
> Based on this, there are likely other areas in the codebase that do not
> handle the bad_utf8_character_code exception correctly.
> My belief is that CouchDB shouldn't accept this input and should have
> rejected the PUT/POST, or should have escaped the input itself before the
> insertion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (COUCHDB-457) Database crash with possibly non-UTF-8 document content
[ https://issues.apache.org/jira/browse/COUCHDB-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Kocoloski closed COUCHDB-457. -- Resolution: Fixed Fix Version/s: 0.10 Assignee: Adam Kocoloski Fixed in COUCHDB-345 > Database crash with possibly non-UTF-8 document content > --- > > Key: COUCHDB-457 > URL: https://issues.apache.org/jira/browse/COUCHDB-457 > Project: CouchDB > Issue Type: Bug >Affects Versions: 0.9.1 >Reporter: James William Dumay >Assignee: Adam Kocoloski > Fix For: 0.10 > > Attachments: bad_utf.py, watercooler.couch > > > See the document with the id "http://www.stephenfry.com/blog/?feed=rss2"; in > the attached db. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-345) "High ASCII" can be inserted into db but not retrieved
[
https://issues.apache.org/jira/browse/COUCHDB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758844#action_12758844
]
Curt Arnold commented on COUCHDB-345:
-
>I'd like to defer decision on this patch until after 0.10. I don't think this
>should block 0.10 and we can fix this in 0.10.x (x > 0) under the following
>conditions: >the 0.10.0 release notes contain a link to this issue and explain
>that the current acceptance of non-utf8 input is discouraged and should not be
>relied >upon as it will be removed in later releases.
The only people who would be intentionally inserting malformed documents would
be those who are intentionally trying to crash a database. Are you saying that
people who are trying to attack a deployed CouchDB instance would be
discouraged from using this attack since it might go away in the future?
Without either of the patches, any CouchDB instance is vulnerable to serious
degradation or failure from anyone who can put a document in the database.
> "High ASCII" can be inserted into db but not retrieved
> --
>
> Key: COUCHDB-345
> URL: https://issues.apache.org/jira/browse/COUCHDB-345
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: OSX 10.5.6
>Reporter: Joan Touzet
> Attachments: badenc1.patch, badtext.tar.gz, enctest.zip,
> reject_invalid_utf8.patch
>
>
> It is possible to PUT/POST a document into CouchDB with a "high ASCII" value
> that cannot be retrieved. This results from not escaping a non-ASCII value
> into \u when PUT/POSTing the document.
> The attached sample code will recreate the problem using the hex value D8 (Ø)
> in a possibly unsavoury test string.
> Sample output against 0.9.0 is as follows:
>
> {
> "ok": true
> }
> {
> "id": "fail",
> "ok": true,
> "rev": "1-76726372"
> }
> {
> "error": "ucs",
> "reason": "{bad_utf8_character_code}"
> }
>
> Please note this defect turned up another problem, namely that the
> bad_utf8_character_code exception thrown by a design document attempting to
> map() the bad document caused Futon to fail silently in building the view,
> with no indication (except via debug log) that there was a failure. The log
> indicated two attempts to build the view, both failing, followed by an
> uncaught exception error for Futon.
> Based on this, there are likely other areas in the codebase that do not
> handle the bad_utf8_character_code exception correctly.
> My belief is that CouchDB shouldn't accept this input and should have
> rejected the PUT/POST, or should have escaped the input itself before the
> insertion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Query server perfromance issues ..
On Wed, Sep 23, 2009 at 11:27 AM, Debasish Ghosh
wrote:
> Looks like I found the problem .. is this an intended change in CouchDB ..
>
> CouchDB wiki documents the following for processing "reset" by the view
> server :
>
> """
> CouchDB sends:
> ["reset"]\n
> The view server responds:
> true\n
> """
> Accordingly I was doing a pattern match in my query server, expecting
> ["reset"] ..
>
> In the latest snapshot, I did a trace and found that CouchDB actually
> sends ["reset", {"reduce_limit":true}] .. hence I was getting an error
> and the query server closes every time ..
>
> Is this the current specification of "reset" ? I changed my code to do
> the corresponding pattern match .. and it now runs fine!
>
> Please confirm.
>
The query_server_spec.rb should cover this, but perhaps it doesn't. I
guess part of the issue is that JS is flexible about function arity in
a way that other languages are not, which makes it really easy to
absorb these sorts of differences.
The command is currently ["reset", query_server_options] although the
JS server works fine if it just gets ["reset"] as well.
Chris
> Thanks.
> - Debasish
>
> On Wed, Sep 23, 2009 at 12:07 AM, Debasish Ghosh
> wrote:
>> Thanks for the suggestions. I have not yet tried query_server_spec.rb.
>> Will do soon to check. Though I logged everything that goes between
>> couch server and the query server. The query server does get null from
>> readLine of System.in with the later snapshots of the codebase that
>> shuts it down. I need to investigate more on how it gets this. But as
>> I mentioned before as well, the same query server runs fine with the
>> earlier snapshot.
>>
>> Will let u know if I find anything meaningful.
>>
>> Thanks.
>> - Debasish
>>
>> On Tue, Sep 22, 2009 at 11:19 PM, Paul Davis
>> wrote:
>>> On Tue, Sep 22, 2009 at 1:11 PM, Debasish Ghosh
>>> wrote:
> It may be that we're flushing the socket with no data, and the Scala
> server is interpreting that as null input. The JS client uses
> readline() implemented in C, so it shouldn't have access to data until
> a line break has been sent by CouchDB.
readLine blocks .. right .. and only comes out with the null input.
The question is how it gets this null string with the new version of
CouchDB.
Is there something different that you were doing in earlier versions.
Just wondering how it still runs with an earlier snapshot of CouchDB
..
Thanks.
- Debasish
>>>
>>> I'm still leaning towards the theory that your server is returning
>>> something that CouchDB doesn't expect. When this happens the Erlang
>>> process controller will shut down the view server by closing its input
>>> stream. Though, theoretically, couchspawnkillable should kill -KILL
>>> the process too, unless there's a tad bit of delay that occurs during
>>> which you're spinning over the stdin stream returning NULL.
>>>
>>> Did you ever try adding tests to query_server_spec.rb and running that
>>> way? I still need to modify that to make it more friendly to run
>>> external view engines, but with a bit of hacking it should at least
>>> point to the inconsistency.
>>>
>>> Paul Davis
>>>
On Mon, Sep 21, 2009 at 6:07 PM, Debasish Ghosh
wrote:
>
> The actual code is something like this ..
> var s = isr.readLine
> while (s != null) {
> // do stuff
> s = isr.readLine
> }
> I wrote the other version just to log what I get back. Now this same
> version works ok with the earlier version of the couchdb server. That's
> what beats me here ..
> Thanks.
> - Debasish
>
> On Mon, Sep 21, 2009 at 5:46 PM, Robert Newson
> wrote:
>>
>> I claim you are ignoring null here because of your comment;
>>
>> while (true) {
>> s = inputstreamreader.readLine
>> if (s == null) // ignore
>> else
>> toJson(s) match {
>> //.. process reset, add_fun etc.
>> }
>> }
>>
>> When System.in is closed this loop will spin; readLine() will always
>> return null. Since System.in is only closed when the JVM is exiting,
>> it is never correct to ignore it and continue processing.
>>
>> The loop I presented is not the same as yours as mine will correctly
>> exit on process termination.
>>
>> readLine() *cannot* return null under any circumstance but the close
>> of the stream (couchdb cannot pass you null this way). System.in is
>> never closed unless the process itself is exiting, and it is never
>> reopened.
>>
>> The mishandling of readLine() is probably hiding the real problem. I
>> would guess you pass invalid JSON to couchdb, or fail to return
>> anything at all, under some conditions. Couch then kills your view
>> server (and would then restart it). The view server, rather than
>> gracefully exiting when this happens, will simple spin, never exiting.
>>
>> B.
>>
>> On Mon
[jira] Commented: (COUCHDB-345) "High ASCII" can be inserted into db but not retrieved
[
https://issues.apache.org/jira/browse/COUCHDB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758741#action_12758741
]
Adam Kocoloski commented on COUCHDB-345:
I think we wanted to keep R12B-5 as the minimum Erlang version for 0.10, so
that means no unicode module.
> "High ASCII" can be inserted into db but not retrieved
> --
>
> Key: COUCHDB-345
> URL: https://issues.apache.org/jira/browse/COUCHDB-345
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: OSX 10.5.6
>Reporter: Joan Touzet
> Attachments: badenc1.patch, badtext.tar.gz, enctest.zip,
> reject_invalid_utf8.patch
>
>
> It is possible to PUT/POST a document into CouchDB with a "high ASCII" value
> that cannot be retrieved. This results from not escaping a non-ASCII value
> into \u when PUT/POSTing the document.
> The attached sample code will recreate the problem using the hex value D8 (Ø)
> in a possibly unsavoury test string.
> Sample output against 0.9.0 is as follows:
>
> {
> "ok": true
> }
> {
> "id": "fail",
> "ok": true,
> "rev": "1-76726372"
> }
> {
> "error": "ucs",
> "reason": "{bad_utf8_character_code}"
> }
>
> Please note this defect turned up another problem, namely that the
> bad_utf8_character_code exception thrown by a design document attempting to
> map() the bad document caused Futon to fail silently in building the view,
> with no indication (except via debug log) that there was a failure. The log
> indicated two attempts to build the view, both failing, followed by an
> uncaught exception error for Futon.
> Based on this, there are likely other areas in the codebase that do not
> handle the bad_utf8_character_code exception correctly.
> My belief is that CouchDB shouldn't accept this input and should have
> rejected the PUT/POST, or should have escaped the input itself before the
> insertion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-345) "High ASCII" can be inserted into db but not retrieved
[
https://issues.apache.org/jira/browse/COUCHDB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758738#action_12758738
]
Paul Joseph Davis commented on COUCHDB-345:
---
I'd vote for applying Adam's patch to reject the utf-8 as a stop gap. Then when
we become more enterprising we should patch mochiweb_request to mux the
incoming body to utf-8. For the short term rejecting non-utf8 seems more sane
than accepting it and rejecting to return the stored data.
On a side note I see a note about xmerl_ucs:from_utf8 and friends. There's a
unicode:is_7bit_clean (or similarly named) function that might be useful.
> "High ASCII" can be inserted into db but not retrieved
> --
>
> Key: COUCHDB-345
> URL: https://issues.apache.org/jira/browse/COUCHDB-345
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: OSX 10.5.6
>Reporter: Joan Touzet
> Attachments: badenc1.patch, badtext.tar.gz, enctest.zip,
> reject_invalid_utf8.patch
>
>
> It is possible to PUT/POST a document into CouchDB with a "high ASCII" value
> that cannot be retrieved. This results from not escaping a non-ASCII value
> into \u when PUT/POSTing the document.
> The attached sample code will recreate the problem using the hex value D8 (Ø)
> in a possibly unsavoury test string.
> Sample output against 0.9.0 is as follows:
>
> {
> "ok": true
> }
> {
> "id": "fail",
> "ok": true,
> "rev": "1-76726372"
> }
> {
> "error": "ucs",
> "reason": "{bad_utf8_character_code}"
> }
>
> Please note this defect turned up another problem, namely that the
> bad_utf8_character_code exception thrown by a design document attempting to
> map() the bad document caused Futon to fail silently in building the view,
> with no indication (except via debug log) that there was a failure. The log
> indicated two attempts to build the view, both failing, followed by an
> uncaught exception error for Futon.
> Based on this, there are likely other areas in the codebase that do not
> handle the bad_utf8_character_code exception correctly.
> My belief is that CouchDB shouldn't accept this input and should have
> rejected the PUT/POST, or should have escaped the input itself before the
> insertion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-345) "High ASCII" can be inserted into db but not retrieved
[
https://issues.apache.org/jira/browse/COUCHDB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758729#action_12758729
]
Adam Kocoloski commented on COUCHDB-345:
I'm on board with that. I don't have the time to properly benchmark the
different patches at the moment, and if we're serious about patching mochijson2
to reject bad input we should get their thoughts on the matter as well.
> "High ASCII" can be inserted into db but not retrieved
> --
>
> Key: COUCHDB-345
> URL: https://issues.apache.org/jira/browse/COUCHDB-345
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: OSX 10.5.6
>Reporter: Joan Touzet
> Attachments: badenc1.patch, badtext.tar.gz, enctest.zip,
> reject_invalid_utf8.patch
>
>
> It is possible to PUT/POST a document into CouchDB with a "high ASCII" value
> that cannot be retrieved. This results from not escaping a non-ASCII value
> into \u when PUT/POSTing the document.
> The attached sample code will recreate the problem using the hex value D8 (Ø)
> in a possibly unsavoury test string.
> Sample output against 0.9.0 is as follows:
>
> {
> "ok": true
> }
> {
> "id": "fail",
> "ok": true,
> "rev": "1-76726372"
> }
> {
> "error": "ucs",
> "reason": "{bad_utf8_character_code}"
> }
>
> Please note this defect turned up another problem, namely that the
> bad_utf8_character_code exception thrown by a design document attempting to
> map() the bad document caused Futon to fail silently in building the view,
> with no indication (except via debug log) that there was a failure. The log
> indicated two attempts to build the view, both failing, followed by an
> uncaught exception error for Futon.
> Based on this, there are likely other areas in the codebase that do not
> handle the bad_utf8_character_code exception correctly.
> My belief is that CouchDB shouldn't accept this input and should have
> rejected the PUT/POST, or should have escaped the input itself before the
> insertion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (COUCHDB-345) "High ASCII" can be inserted into db but not retrieved
[
https://issues.apache.org/jira/browse/COUCHDB-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758726#action_12758726
]
Jan Lehnardt commented on COUCHDB-345:
--
I'd like to defer decision on this patch until after 0.10. I don't think this
should block 0.10 and we can fix this in 0.10.x (x > 0) under the following
conditions: the 0.10.0 release notes contain a link to this issue and explain
that the current acceptance of non-utf8 input is discouraged and should not be
relied upon as it will be removed in later releases.
> "High ASCII" can be inserted into db but not retrieved
> --
>
> Key: COUCHDB-345
> URL: https://issues.apache.org/jira/browse/COUCHDB-345
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.9
> Environment: OSX 10.5.6
>Reporter: Joan Touzet
> Attachments: badenc1.patch, badtext.tar.gz, enctest.zip,
> reject_invalid_utf8.patch
>
>
> It is possible to PUT/POST a document into CouchDB with a "high ASCII" value
> that cannot be retrieved. This results from not escaping a non-ASCII value
> into \u when PUT/POSTing the document.
> The attached sample code will recreate the problem using the hex value D8 (Ø)
> in a possibly unsavoury test string.
> Sample output against 0.9.0 is as follows:
>
> {
> "ok": true
> }
> {
> "id": "fail",
> "ok": true,
> "rev": "1-76726372"
> }
> {
> "error": "ucs",
> "reason": "{bad_utf8_character_code}"
> }
>
> Please note this defect turned up another problem, namely that the
> bad_utf8_character_code exception thrown by a design document attempting to
> map() the bad document caused Futon to fail silently in building the view,
> with no indication (except via debug log) that there was a failure. The log
> indicated two attempts to build the view, both failing, followed by an
> uncaught exception error for Futon.
> Based on this, there are likely other areas in the codebase that do not
> handle the bad_utf8_character_code exception correctly.
> My belief is that CouchDB shouldn't accept this input and should have
> rejected the PUT/POST, or should have escaped the input itself before the
> insertion.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (COUCHDB-510) build windows installer as part of 'make dist' on windows
[ https://issues.apache.org/jira/browse/COUCHDB-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hammond updated COUCHDB-510: - Attachment: win_installer.patch > build windows installer as part of 'make dist' on windows > - > > Key: COUCHDB-510 > URL: https://issues.apache.org/jira/browse/COUCHDB-510 > Project: CouchDB > Issue Type: Improvement > Components: Build System >Reporter: Mark Hammond > Attachments: win_installer.patch > > > Attaching a patch which creates an installer using 'inno' when ' make dist' > is run on windows. Uploading in the hope of getting a quick review from > nslater. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (COUCHDB-510) build windows installer as part of 'make dist' on windows
build windows installer as part of 'make dist' on windows - Key: COUCHDB-510 URL: https://issues.apache.org/jira/browse/COUCHDB-510 Project: CouchDB Issue Type: Improvement Components: Build System Reporter: Mark Hammond Attachments: win_installer.patch Attaching a patch which creates an installer using 'inno' when ' make dist' is run on windows. Uploading in the hope of getting a quick review from nslater. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Special interest CouchDB mailing lists
also > we could also have things like local-...@couchdb.apache.org etc +1 (though i do understand at this point my opinion is a grain of sand)
Re: Special interest CouchDB mailing lists
> What would you think to doing: > desk...@couchdb.apache.org > Making this an official CouchDB special interest list? +1 (though i do understand at this point my opinion is a grain of sand) Perhaps re...@... or something like post-re...@... would be a an appropriate name for a generic spark generator mailing list. A special interest that gathers momentum and spawns from this could postion itself in a range that intuitively indicates the type of discussion that may be expected, reducing maintenance overhead. Something like (only an example...of course the topic-type split would require better resolution): relax-...@couchdb.apache.org // app dev topics of primarily authoring erlang libs ... relax-0...@couchdb.apache.org // app dev topics of primarily authoring erlang libs ... relax-...@couchdb.apache.org // app dev topics of primarily authoring javascript libs ... relax-...@couchdb.apache.org // app dev topics of working with standard libs and methods relax-0...@couchdb.apache.org // topics of performance testing against standard libs and methods Any newly spawned special interest topic would position itself in relation to the existing groups...such as futon colour scheme or layout may be relax-0...@couchdb.apache.org or purely layout discussion could be relax-0@couchdb.apache.org...though such granularity may not neccessarily be expected, the option exists if eventually required. For new user and even longtime users it would be intuitive to find the dev category of special interest at any time across a vast range of lists. Specific apps could indicate their use using the relax-cat and each list could indicate the apps that are associated with it... New special interest discussion lists could be determined quickly using a form linked to the couchdb homepage that requires a proposed relax-cat ie relax-...@couchdb.apache.org supported by a discussion stack from the parent list. Concerns addressed would be system maintence overhead and user self-orientation ie quickly finding what you are looking for. One additional benefit is that special interest clusters of the user base and therefore effectively the nature of couchdb would be clearly demonstrated in a relaxing way. I hope this has relevence and is helpful.
