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 http://wiki.apache.org/couchdb/HTTP_Document_API#head-63e138cce0b3ffd6b2cf9a6336eb90ddf05a5afe: 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 http://wiki.apache.org/couchdb/HTTP_Document_API#head-44175f1142d4ecb321a5eb12a0dad6b9a5fdc59d 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
