ah, I just ran into this today when I was checking the validity of my
xhtml.
core team, is this just an omission? If so, Jarkko, I would definitely
be willing to help you out on this. I've been trying to find where the
restful helper '_url' methods are created w/o much luck so far. Or can
someone point me in the right direction?
That's funny, because form tags double encode named routes.
<%= form_tag foo_path(...) %>
foo_path converts to an unencoded string
form_tag calls url_for which encodes all strings
form_tag calls tag which processes and encodes all attributes.
I'd say you can't go wrong without a good set of test cases to back you up.
that last one is what I want; I think most people would want the same
thing, but that is too 'tricky'.
Rick, as you indirectly pointed out, doing it at the resource '_url'
level is not the right place to do it (ie; what if it is used in a
method that already encodes, or is printed to text and not html where
it doesn't need to be encoded, etc).
That would make link_to the correct place to change this logic. Since
url_for already handles strings, can we replace this logic in
ActionView/Helpers/UrlHelper#link_to:
# url = options.is_a?(String) ? options : self.url_for(options,
*parameters_for_method_reference)
url = self.url_for(options, *parameters_for_method_reference)
Not quite - rather that the url_for helper escapes ALL raw strings passed.
There was a patch for that (and other URl escaping bugs) literally a month ago. Nobody noticed.