You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Wout Mertens <wo...@gmail.com> on 2009/03/07 09:49:46 UTC
%2f vs / in _design vs regular docs?
Hi all,
I noticed the following discrepancy: When you try to request a design
document, and you encode the / as %2F, couchdb will redirect you to a
URL with %2f decoded to /, which works.
However, for any other documents, you must encode the / as %2f. For
_view URLs, you must put /. For JSON key values, you can use both.
Examples:
[info] [<0.19011.2>] 127.0.0.1 - - 'GET' /vavoom/_design%2Fmacaddr 301
[info] [<0.19020.2>] 127.0.0.1 - - 'GET' /vavoom/_design/macaddr 304
[info] [<0.19029.2>] 127.0.0.1 - - 'GET' /vavoom/mac/00:50:56:00:02:02
404
[info] [<0.19029.2>] 127.0.0.1 - - 'GET' /vavoom/mac
%2f00:50:56:00:02:02 200
[info] [<0.21779.2>] 127.0.0.1 - - 'GET' /vavoom/_view%2fimages%2fall?
include_docs=true 404
[info] [<0.21807.2>] 127.0.0.1 - - 'GET' /vavoom/_view%2fimages/all?
include_docs=true 404
[info] [<0.21807.2>] 127.0.0.1 - - 'GET' /vavoom/_view/images%2fall?
include_docs=true 405
[info] [<0.21807.2>] 127.0.0.1 - - 'GET' /vavoom/_view/images/all?
include_docs=true 200
[info] [<0.22633.2>] 127.0.0.1 - - 'GET' /vavoom/_all_docs?startkey=
%22mac/00:50:56:00:02:02%22&limit=1 200
[info] [<0.22633.2>] 127.0.0.1 - - 'GET' /vavoom/_all_docs?startkey=
%22mac%2f00:50:56:00:02:02%22&limit=1 200
Is there logic behind this? Would it be possible to allow unchanged /
in keys that are accessed directly?
The reason I ask is that it would be very natural to put the type of a
document as a prefix to the document. This gives you instant views like
[info] [<0.20301.2>] 127.0.0.1 - - 'GET' /vavoom/_all_docs?startkey=
%22mac/%22&endkey=%22mac?%22 304
and for a wiki you could have subsections under like _show/wiki/
showpage/section/subsection/page
Cheers,
Wout.
Re: %2f vs / in _design vs regular docs?
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Mar 9, 2009 at 7:57 AM, Wout Mertens <wm...@cisco.com> wrote:
> Well IMHO that punishes libraries that try to do good things for the user,
> now they have to special-case _design/ to avoid a network round-trip. I'd be
> happier if both ways just worked.
Whoops, missed this point.
The reasoning here is that it's better to have a single resource at a
particular location. It's probably just bike-shedding but in this
case, libraries have a choice: implement the special case or pay a
slight cost for the redirect.
Chris
--
Chris Anderson
http://jchris.mfdz.com
Re: %2f vs / in _design vs regular docs?
Posted by Chris Anderson <jc...@apache.org>.
On Mon, Mar 9, 2009 at 7:57 AM, Wout Mertens <wm...@cisco.com> wrote:
> On Mar 7, 2009, at 7:05 PM, Chris Anderson wrote:
>
>> On Sat, Mar 7, 2009 at 12:49 AM, Wout Mertens <wo...@gmail.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> I noticed the following discrepancy: When you try to request a design
>>> document, and you encode the / as %2F, couchdb will redirect you to a URL
>>> with %2f decoded to /, which works.
>>>
>>
>>> _show/wiki/showpage/section/subsection/page
>>
>> The problem becomes distinguishing between documents and attachments.
>
>
>> Docids are always urlencoded, with the exception of _design/ docids,
>> which can be requested with the / unencoded (the redirect was put
>> there to make that rule self-documenting.)
>
> Well IMHO that punishes libraries that try to do good things for the user,
> now they have to special-case _design/ to avoid a network round-trip. I'd be
> happier if both ways just worked.
>
>> Slashes in attachment names can also be used unencoded, so
>>
>> /db/wiki/showpage/section/subsection/page address the attachment named
>> "showpage/section/subsection/page" on the document with id "wiki"
>
> Right. So in summary, the rule is either of these:
>
> 1. http://server/dbname/document/path/in/attachment
> 2. http://server/dbname/_design/document
also 3. http://server/dbname/_design/document/with/attachment.ext
Currently it's just _design that's special cased. The only other _
docs couchdb allows are _local and they are never seen by end users,
so for now the _design case has worked. There's room to add a resource
at /db/_design/ that lists all the design docs.
>
> where document is always url-encoded? If so I'll update the wiki.
> (API_Cheatsheet and HTTP_Document_API)
Thanks for the wiki-update offer. That'd be a big help!
>> This was discussed intensively on this thread:
>> http://www.mail-archive.com/dev@couchdb.apache.org/msg00018.html
>
> I should have found that, sorry, I didn't think of search first :(
Don't worry about it.
--
Chris Anderson
http://jchris.mfdz.com
Re: %2f vs / in _design vs regular docs?
Posted by Wout Mertens <wm...@cisco.com>.
On Mar 7, 2009, at 7:05 PM, Chris Anderson wrote:
> On Sat, Mar 7, 2009 at 12:49 AM, Wout Mertens
> <wo...@gmail.com> wrote:
>> Hi all,
>>
>> I noticed the following discrepancy: When you try to request a design
>> document, and you encode the / as %2F, couchdb will redirect you to
>> a URL
>> with %2f decoded to /, which works.
>>
>
>> _show/wiki/showpage/section/subsection/page
>
> The problem becomes distinguishing between documents and attachments.
> Docids are always urlencoded, with the exception of _design/ docids,
> which can be requested with the / unencoded (the redirect was put
> there to make that rule self-documenting.)
Well IMHO that punishes libraries that try to do good things for the
user, now they have to special-case _design/ to avoid a network round-
trip. I'd be happier if both ways just worked.
> Slashes in attachment names can also be used unencoded, so
>
> /db/wiki/showpage/section/subsection/page address the attachment named
> "showpage/section/subsection/page" on the document with id "wiki"
Right. So in summary, the rule is either of these:
1. http://server/dbname/document/path/in/attachment
2. http://server/dbname/_special/document
where document is always url-encoded? If so I'll update the wiki.
(API_Cheatsheet and HTTP_Document_API)
> This was discussed intensively on this thread:
> http://www.mail-archive.com/dev@couchdb.apache.org/msg00018.html
I should have found that, sorry, I didn't think of search first :(
Wout.
Re: %2f vs / in _design vs regular docs?
Posted by Chris Anderson <jc...@apache.org>.
On Sat, Mar 7, 2009 at 12:49 AM, Wout Mertens <wo...@gmail.com> wrote:
> Hi all,
>
> I noticed the following discrepancy: When you try to request a design
> document, and you encode the / as %2F, couchdb will redirect you to a URL
> with %2f decoded to /, which works.
>
> _show/wiki/showpage/section/subsection/page
The problem becomes distinguishing between documents and attachments.
Docids are always urlencoded, with the exception of _design/ docids,
which can be requested with the / unencoded (the redirect was put
there to make that rule self-documenting.)
Slashes in attachment names can also be used unencoded, so
/db/wiki/showpage/section/subsection/page address the attachment named
"showpage/section/subsection/page" on the document with id "wiki"
This was discussed intensively on this thread:
http://www.mail-archive.com/dev@couchdb.apache.org/msg00018.html
Here's a relevant ticket but the discussion was not on the ticket:
https://issues.apache.org/jira/browse/COUCHDB-167
Chris
--
Chris Anderson
http://jchris.mfdz.com