On Oct 14, 2009, at 2:03 PM, Chris Anderson wrote:
On Wed, Oct 14, 2009 at 10:43 AM, Jason Davies
<[email protected]> wrote:
Hi Sven,
On 14/10/2009 18:34, Sven Helmberger wrote:
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.
We redirect /dbname/_design%2F/foo to /dbname/_design/foo. These
aren't the
same URLs, so there shouldn't be an endless loop here, unless your
library
is prematurely decoding URL-encoded characters.
As for whether this is a good thing or not, I'm ambivalent at the
moment.
I'm not 100% sure, but I think the main reason for special-casing
design
docs in this way was to make developing CouchApps easier (you can use
../app2 instead of ../../_design%2Fapp2).
My motivation in adding the redirect was that anytime users see %2F on
the screen it's a total bug. If design docs are the entry points for
CouchApps, then their URLs are always on the screen. If they have %2F
in them then we have just shafted our users bad.
I know it's a bit special-casey but I hope you understand the
motivation is user comfort.
Chris
I honestly forgot we were still doing this redirect. Would it be so
bad to just serve the document in both cases?
GET _design/foo -> 200
GET _design%2Ffoo -> 200
GET _local/bar -> 200
GET _local%2Fbar -> 200
That seems like the relaxed approach to me. Best, Adam