Byron Young wrote on 2009-06-12:
> Hey everybody,
>
> I ran into an issue at $work where we keep passing the same
> $query_params hashref to a number of uri_for() calls successively,
> but if there are characters in the query params that need to be
> escaped they get escaped each time, leading to sequences like
>
> ?filter=Not%25252BRun
>
> after the same $query_params have been run through uri_for a few of
> times (because the '%' keeps getting escaped). The query hash was
> originally { filter => 'Not Run' }.
>
> So, we patched uri_for() here at work to create a copy of $params
> and work with that, and that fixes the issue. However, it seems
> like such a simple fix that I feel like it must have been thought
> of and discussed and shot down in the past, but I didn't find
> anything in the list archives indicating that. Is there some
> reason uri_for() does things that way?
>
> If not I'll gladly supply patch + test.
>
> Thanks,
> Byron
>
> _______________________________________________ List:
> [email protected] Listinfo: http://lists.scsys.co.uk/cgi-
> bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-
> archive.com/[email protected]/ Dev site:
> http://dev.catalyst.perl.org/
I also noticed that the docs for uri_for used to warn of the destructiveness
but that warning has been removed in more recent versions. I'd like to suggest
that it be added back and made more prominent if there really is a good reason
for mangling the caller's data. I can provide a doc patch in that case, too.
Byron
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
