couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freddy Bowen <>
Subject Re: ID encoding inconsistencies
Date Wed, 24 Jun 2009 14:32:30 GMT
Hello David,

I'm not well informed of the rationale behind slash encoding, but I did
check your experience against the wiki.

a) for a document "foo" with attachment "bar/baz", both "foo/bar/baz" and
> "foo/bar%2Fbaz" work. I believe that only the latter should be possible as
> that would be consistent with other IDs (design documents, view names and
> document IDs)

Corresponds to documented behavior. From

Attachments may have embedded */* characters that are sent unescaped to
> CouchDB. You can use this to provide a subtree of attachments under a
> document. A DocID must have any */* escaped as *%2F*. So if you have
> document *a/b/c* with an attachment *d/e/f.txt*, you would be able to
> access it at http://couchdb/db/a%2fb%2fc/d/e/f.txt .

On the other hand, your finding that

b) if a design document contains a view with a slash, then calling
> "/testdb/_design/lolcats/_
> view/all%2Fyour%2Fbase" works, while
> "/testdb/_design/lolcats/_view/all/your/base" gives an HTTP 405 Method Not
> Allowed response instead of a 404 which I think would be correct and/or
> consistent with the other cases where IDs are not found, right? It should
> act like when calling a non-existant view I think.

is at odds with the documented behavior.  From

You can have */* as part of the DocID but if you refer to a document in a
> URL you must always encode it as *%2F*. One special case is *_design/*documents, those
accept either
> */* or *%2F* for the */* after *_design*, although */* is preferred and *
> %2F* is still needed for the rest of the DocID.

So maybe a ticket for (b) is in order?

- FB

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message