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

Reply via email to