When a partition ID includes special characters, such as '/' or '+', Nano should escape those using encodeURIComponent, just as it does already for document ID's, design document names, database names, and so forth.
Current Behavior
Nano just concatenates the partition ID into the URI without escaping, which is dangerous:
Incorporate encodeURIComponent into the following methods:
partitionInfo
partitionedList
partitionedFind
partitionedSearch
partitionedView
partitionedListAsStream
partitionedFindAsStream
partitionedSearchAsStream
partitionedViewAsStream
Steps to Reproduce (for bugs)
Any partitioned call involving special characters, such as a base64-encoded string, will randomly fail if the encoding produces special characters:
myDb.partitionedList(base64.encode(...))
Context
We are temporarily working around this by doing the encodeURIcomponent in our app, before passing the partition ID to Nano. This allows our queries to succeed for now, since we convert characters like '+' to '%2b' before passing to Nano.
This implies that fixing this bug would be a breaking change, since presumably other people have run into the same issue and have adopted the same workaround. If the client app calls encodeURIcomponent, and then Nano itself calls encodeURIcomponent again, a character like '+' would become '%2b' in the client code, and then '%252b' in Nano, which is wrong.
So, while Nano should address this eventually, it may be necessary to wait for a v10 breaking release.
Expected Behavior
When a partition ID includes special characters, such as '/' or '+', Nano should escape those using
encodeURIComponent, just as it does already for document ID's, design document names, database names, and so forth.Current Behavior
Nano just concatenates the partition ID into the URI without escaping, which is dangerous:
https://github.com/apache/couchdb-nano/blob/2d4bd719e4f08915ed9c0ef7953e901391ce4239/lib/nano.js#L1050
Possible Solution
Incorporate
encodeURIComponentinto the following methods:partitionInfopartitionedListpartitionedFindpartitionedSearchpartitionedViewpartitionedListAsStreampartitionedFindAsStreampartitionedSearchAsStreampartitionedViewAsStreamSteps to Reproduce (for bugs)
Any partitioned call involving special characters, such as a base64-encoded string, will randomly fail if the encoding produces special characters:
Context
We are temporarily working around this by doing the
encodeURIcomponentin our app, before passing the partition ID to Nano. This allows our queries to succeed for now, since we convert characters like '+' to '%2b' before passing to Nano.This implies that fixing this bug would be a breaking change, since presumably other people have run into the same issue and have adopted the same workaround. If the client app calls
encodeURIcomponent, and then Nano itself callsencodeURIcomponentagain, a character like '+' would become '%2b' in the client code, and then '%252b' in Nano, which is wrong.So, while Nano should address this eventually, it may be necessary to wait for a v10 breaking release.
Your Environment