On Jan 28, 10:59 am, Jonathan Lundell <jlund...@pobox.com> wrote:
>
> It's no so obviously a bug.
Agreed.
> URL('f',args=['arg1','arg2']) is /app/ctl/f/arg1/arg2 or
> /app/ctl/f/'arg1'/'arg2' (quotes added for clarity)
>
> so suppose arg2 is ''; the consistent transformation is:
>
> URL('f',args=['arg1','']) -> /app/ctl/f/'arg1'/'' or /app/ctl/f/arg1/ without
> the quotes
>
> I see three defensible choices. In all cases, .../arg1 -> ['arg1']
>
> 1. .../arg1/ -> ['arg1', ''] .../arg1// -> ['arg1', '', '']
>
> 2. .../arg1/ -> ['arg1'] .../arg1// -> ['arg1', '']
>
> 3. .../arg1/ -> ['arg1'] .../arg1// -> ['arg1']
>
> #1 follows Python split/join. Each trailing slash is another empty-string arg.
>
> #2 adds a trailing slash on output iff the last arg is '', and always deletes
> one trailing slash on input if it's present.
>
> #3 ignores all trailing slashes (that's the current code)
>
> #1 is the most simple, consistent and elegant, it seems to me. Its drawback
> is that we sort of expect that .../arg1 and .../arg1/ are the same URL. But
> that's not always the case, and I don't see a big problem with saying that a
> visible difference has consequences. Also, we're mostly generating our own
> URLs, so we control what they look like; they're not often being typed.
#1 also seems to go along with the spirit of the RFC where the slash
is a segment separator.
The only worry is that I think some browsers add the trailing slash if
it is not there (don't quote me on this though), but does it matter?.
> #2 follows the expectation that .../arg1 and .../arg1/ are the same, but it
> does so at the expense of treating '' differently from all other arg values.
>
> #3 takes a different approach, flatly declaring that trailing slashes are
> never significant. The downside is that trailing empty args ('') cannot be
> made explicit in the URL (though in fairness, in current web2py they're
> illegal, so...).
>
> We should get this resolved before Massimo releases the next stable version.
> Massimo, do you have a preference? I'm leaning toward #1 at the moment, but
> not very strongly.
>
