Bug in URI ?!
paulm at paulm.com
Sun Sep 10 17:09:07 BST 2006
On 8/16/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
> Dominic Mitchell wrote:
> > David Dorward wrote:
> >> Paul Makepeace wrote:
> >>> URI::_query::query_form() which makes query strings:
> >>> $self->query(@query ? join('&', @query) : undef);
> >>> Now as anyone in web standards knows, that ought to be '&'.
> >> Only if the URI is being written in HTML. Since, to judge from the
> >> module name, it is just a URL there shouldn't be any markup language
> >> specific encoding going on. Once you have the URI you should run it
> >> though a suitable encoding method before using it in markup though.
> > Once again, this highlights how poor our tools our... If templating
> > systems did HTML escaping by default, this wouldn't be an issue (i.e.
> > having to remember to html encode all strings that could possibly
> > contain user input). When will our frameworks grow up?
> They already did, you just weren't looking.
> package MyApp::View::HTML
> use base qw/Catalyst::View::TT/;
> STASH => Template::Stash::EscapeHTML->new
Has anyone actually used this? Apart from it not passing its own POD
coverage tests (and thus requiring a force install), it seems to
simply result in the whole template output being escaped, HTML 'n all.
Admittedly I haven't looked into this very much but since it wasn't
even passing tests and that people cite modules on lists without
trying them I thought I'd ask first.
(Nice idea though.)
I think a less heavyweight solution would simply be to be able to
configure c.uri_for to produce HTML-escaped URLs (or not), which IMO
it ought to be default. It's a _web_ app framework after all... Even
Template's own URL plugin does this, putting correctness aside for
More information about the london.pm