From dev-return-6849-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Wed Oct 14 17:35:07 2009 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 45082 invoked from network); 14 Oct 2009 17:35:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Oct 2009 17:35:06 -0000 Received: (qmail 21946 invoked by uid 500); 14 Oct 2009 17:35:06 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 21875 invoked by uid 500); 14 Oct 2009 17:35:06 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 21865 invoked by uid 99); 14 Oct 2009 17:35:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Oct 2009 17:35:06 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sven.helmberger@gmx.de designates 213.165.64.20 as permitted sender) Received: from [213.165.64.20] (HELO mail.gmx.net) (213.165.64.20) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 14 Oct 2009 17:35:03 +0000 Received: (qmail invoked by alias); 14 Oct 2009 17:34:41 -0000 Received: from i59F56CE0.versanet.de (EHLO [192.168.0.101]) [89.245.108.224] by mail.gmx.net (mp036) with SMTP; 14 Oct 2009 19:34:41 +0200 X-Authenticated: #1594082 X-Provags-ID: V01U2FsdGVkX19dxpIJBGhd9jagFRgC8wCx8Ne9IMlN1+XpPM84SN sfvQUnTS/kdLEf Message-ID: <4AD60BB1.5010803@gmx.de> Date: Wed, 14 Oct 2009 19:34:41 +0200 From: Sven Helmberger User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: dev@couchdb.apache.org Subject: %2F vs / Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Hi! In my function as jcouchdb developer, I've been following the CouchDB development some time and found something that seems a little strange to me. There seem to have been multiple iterations how %2F is treated vs / in different access scenarios, with the current (0.10.0) behaviour seeming a little odd. First, there suddenly was a 301 response somewhere where it wasn't before. While accessing design documents, %2F using URLs get redirected to / ones which makes the new apache http client 4.0 java lib puke because it (rightfully, I think?) complains that it is receiving a redirect to the same URL which it interprets as endless loop thus being exception worthy. I interpreted this finding as the 301 offering backwards compatibility in some scenarios, but obviously I don't want jcouchdb driver to do unescessary requests and I don't really like it following 30x automatically either (which it accidentally did because I forgot to disable that when switching from commons httpclient 3.x to 4.0). Disabling 30x led to a situation where some unit tests failed (Design Doc accessing ones), so I fiddled around to find a combination that satisfied all tests. The solution I seemed to have found was to escape / into %2F but only if the document id does not start with the magic "_design/". For reasons I can't seem to put my finger on, this behaviour seems weird. Are my observations correct? Is this the way to handle the issue? Regards, Sven Helmberger