Robin Smidsrød wrote:
So my vote is for letting it stay fixed. The old implementation was obviously wrong.
Yes, it took me a while to get my head around it it, but the old implementation was definitely "wrong" in the sense that it didn't correctly implement URI escaping as it is defined in RFC 2396 and RFC 2732 and implemented by URI::Escape. My bad. Breaking the behaviour of the existing filter in an attempt to fix it was also wrong. My bad again, although it was a case of "My bad if I did, my bad if I didn't". So it was my badness either way! Using incorrect examples of the broken filter in several places, including dead trees, was triple-bad on my part. If I had known any better at the time, I wouldn't have done it. But I didn't, so I did. And now my badness runneth over. Anyway... here's my take on the situation: Robin's example shows exactly how the URI filter is *supposed* to be used. It is for escaping any string so that you can safely use it as a URL parameter. That necessarily includes escaping any reserved characters that could otherwise have special meaning in the constructed URL. e.g. [% redirect = "http://there.com/blah?x=10&y=20" %] <a href="http://here.com/blah?redirect=[% redirect | uri %]">...</a> Given that this is correct according to the RFCs, I think we must keep it this way. Although I sympathise with those people whose templates have become broken (for which I offer my sincere apologies), I think it would be wrong to now revert back to the demonstrably incorrect behaviour. Particularly if that means re-screwing over those people who have diligently updated their templates to Do The Right Thing. I propose we add a new 'url' filter which implements the old behaviour. That is, to URI encode a string except for the reserved characters: ; / ? : @ & = + $ , [ ] If necessary, we can make the filter smart enough to recognise reserved characters in query parameters and escape them, while leaving them untouched in the path: e.g. http://example.com/blah?x=10&b=20/30/40 ^^ ^ ^ ^ don't escape these do escape these => http://example.com/blah?x=10&b=20%2F30%2F40 For those that want the uri filter to work in the old way (i.e. as a stop-gap until they can update their templates), they can simply map one to the other: Template->new({ FILTERS => { uri => \&Template::Filters::url_filter, }, }); And those that don't mind what the damn filter is called, as long as it does the job properly, will only have to change one character in the filter name: uri => url Does that sound like a good plan to make the least number of people displeased for as little time as possible? A _______________________________________________ templates mailing list [email protected] http://lists.template-toolkit.org/mailman/listinfo/templates
