[Catalyst] Slash characters in a path argument

Tomas Doran bobtfish at bobtfish.net
Wed Sep 28 15:45:49 GMT 2011


On 27 Sep 2011, at 15:41, Ian Wells wrote:

> I have a string I want to use as one argument to a controller.  It's  
> user-sourced and occasionally has slashes in.
>
> I use this as
>
>     $c->uri_for('/controller/action', 'string/with/slashes');
>
> (done in TT, as it happens, but the results are the same)
>
>
> I'd like that argument to be the first argument of my controller.   
> uri_for doesn't encode the slashed string, so that gives me / 
> controller/action/string/with/slashes, and misses my one-argument  
> action.

Yes, this is as we rely on being able to just concatenate path parts  
for uri_for.

However if you supply uri_for with an action object (or use  
uri_for_action), then encoding will happen as expected in CaptureArgs  
and Args.

> If I URI-encode it, things work better in the Catalyst webserver,  
> <app>_server.pl
>
> $c->uri_for('/controller/action', 'string%2Fwith%2Fslashes');
>
> The url is then /controller/action/string%2Fwith%2Fslashes and the  
> action is found; Catalyst even decodes it, and we're laughing.
>
> However, this leads to weird things happening.  If you run under  
> lighttpd/fastcgi, it thoughtfully decodes the slashes for you, which  
> brings us back to the first case: it misses my 1-argument controller  
> and gets me a 404.  Catalyst reports:
>
> [debug] "GET" request for "content/series/David%20Audley%20/%20Jack 
> %20Butler:%20Chronological%20Order" from "xx.xx.xx.xx"
> [debug] Path is "/"
> [debug] Arguments are "content/series/David Audley / Jack Butler:  
> Chronological Order"

You haven't given us any of the information needed to help you debug  
this, so I can't help.

This _does_ work (as I'm using it).

> Now, one answer to this is to encode slashes in such strings as non- 
> uri-encoding.  Another is to have special-case actions that can have  
> slashed arguments in them.  A third would be to change lighttpd's  
> behaviour - there's a bug open for exactly that but no activity on  
> it; also, I suspect other webservers behave similarly...
>
>
> Has anyone come up against this before?  Any tips?

Start with the documentation for use_request_uri_for_path => 1 in  
Catalyst.pm

If that doesn't help, hop onto irc (or reply to this mail) and paste  
some info like the startup debug and full request debug please?

Cheers
t0m




More information about the Catalyst mailing list