I have a string I want to use as one argument to a controller.  It&#39;s user-sourced and occasionally has slashes in.<br><br>I use this as <br><br>    $c-&gt;uri_for(&#39;/controller/action&#39;, &#39;string/with/slashes&#39;);<br>

<br>(done in TT, as it happens, but the results are the same)<br><br><br>I&#39;d like that argument to be the first argument of my controller.  uri_for doesn&#39;t encode the slashed string, so that gives me /controller/action/string/with/slashes, and misses my one-argument action.<br>

<br>If I URI-encode it, things work better in the Catalyst webserver, &lt;app&gt;_<a href="http://server.pl">server.pl</a><br><br>$c-&gt;uri_for(&#39;/controller/action&#39;, &#39;string%2Fwith%2Fslashes&#39;);<br><br>The url is then /controller/action/string%2Fwith%2Fslashes and the action is found; Catalyst even decodes it, and we&#39;re laughing.<br>

<br>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:<br>

<br>[debug] &quot;GET&quot; request for &quot;content/series/David%20Audley%20/%20Jack%20Butler:%20Chronological%20Order&quot; from &quot;xx.xx.xx.xx&quot;<br>[debug] Path is &quot;/&quot;<br>[debug] Arguments are &quot;content/series/David Audley / Jack Butler: Chronological Order&quot;<br>

<br>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&#39;s behaviour - there&#39;s a bug open for exactly that but no activity on it; also, I suspect other webservers behave similarly...<br>

<br><br>Has anyone come up against this before?  Any tips?<br><br>Cheers,<br>-- <br>Ian.<br>