[Catalyst] Handling arguments with Reges vs the meaning of paths

[Bill Moseley]

On Thu, Jan 05, 2006 at 02:18:44PM -0800, apv wrote:
> Now, I am arguing that the Regex argument (not snippet) handling is
> conceptually broken and should be changed.
> 
>  http://host.xyz/this/is/a/path
>  http://host.xyz/?these=1;are=1;arguments=1

Those are parameters.  Arguments are what follow the action.

> If I have a Regex ('whatever/(STOP-HERE)$'), I really mean the '$'. I  
> want it to stop.
> I don't want to slurp up more path into arguments because it's not  
> mapping to anything the application does.
>     
> http://host.xyz/whatever/STOP-HERE/meaningless/misleading/nonsense/ 
> should/404

I'm not sure I'm clear what you are saying.  Why not just ignore the
arguments?

It's how the CGI standard works and all the other actions work.  Why
should the Regex matching be different?

> So, I'm in the position where I'm about to start adding:
>   my ( $self, $c, $path_args ) = @_;
>   die 404 if $path_args;
> into most all my Regex controllers.

But, you wouldn't do that for Local and Path actions?


> The solution, if anyone agrees, is to allow '$', '\Z', '\z' to truly
> end what the Regex controller will accept. If there is more, it
> should be kicked  down to the default(s) where several (or all) can
> be handled at once instead of  per controller sub.

But the $ defines where the action ends and the arguments begin, right?

If $ instead matches the end of the path then someone that wants
arguments cannot as easily get them.  As it is now if you really don't
want to accept requests with extra PATH_INFO you can just check
$path_args, as in your example above.




-- 
Bill Moseley
moseley at hank.org