Thanks for your reply.
Currently, a customizable 404 page is returned if (1) URI doesn't match any route configured in the application, or (2) user called die 404; (or its longer analog) in the handler. Cookies and parameters have signature like $request->param( name => qr/.../ ); . Sorry for not explaining in the question.
And yes, fixing path_info() into "untaint" style was my first thought. However, after trying it out I noticed that only few paths in an actual application require path_info, and in those that don't I keep using a boilerplate along the lines of
die 404 if $request->path_info(qr/.*/);
Consider something like
/questions /questions/tagged/\w+
I would like to get a 404 upon requesting /questions/foobar automatically, without having to specify anything in the handler.
Also if there's something like
/history/\d{4}/\4{2}
the path is likely to be processed with further regexp extracting specific values, so why not do it for the user at once and return captured values?
That's why I'm thinking of going for a more convoluted API and deprecating path_info() altogether. Complex APIs are evil, but so is boilerplate code and unneeded repetition.
In reply to Re^2: Cool uses for path_info
by Dallaylaen
in thread Cool uses for path_info
by Dallaylaen
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |