I had another problem with url argument handling that came in was
"/app/controller/function/arg1\r".
The default regex matching ( regex_args.match(request.raw_args( )) for
the arguments would return false and then the application would
respond with an "invalid request" error. It is not obvious from the
error what the reason for failure is.
Obviously this doesn't happen when visiting sites in a browsers, but
it can be more of an issue for a json-rpc style application.
Should the url be "sanitized" beforehand?
On Jan 28, 12:58 am, Jonathan Lundell <jlund...@pobox.com> wrote:
> On Jan 27, 2011, at 12:48 PM, DenesL wrote:
>
>
>
> >>>> Now, trailing slashes are stripped, so the first two examples about give
> >>>> ['arg1'], as does /a/c/f/arg1/////
>
> >>> Maybe that should be parsed as ['arg1', '', '', '', '']
>
> >> Maybe, but it seems to me that it's confusing unless we also recognize a
> >> single trailing slash as an empty arg. I don't have a strong opinion.
>
> > Note that the number of empty strings ('') is one less than the number
> > of slashes:
>
> > /arg1/////
> > /arg1/empty/empty/empty/empty/nothing_here
>
> Yes.
>
> Still, it bothers me that arg1 == arg1/ != arg1//; <ignore exactly one
> (optional) trailing slash> seems like an odd rule.
>
> Notice also that '/'.join(['arg1', '']) is 'arg1/', not 'arg1//'.
>
> I'm open to changing it if you (or someone else) feels strongly about it--I'd
> just have to change a call to rstrip to a conditional trim-one-character if
> the string endswith('/'), so it's not a big deal. The important thing is for
> it to be well defined.
