Hassan S. wrote:
On Fri, Jan 2, 2009 at 4:08 PM, Jonathan R.
… url_for [helper method] seperates query parameters with
& url_for the controller method does
Why “unpredictable”? HTML requires ampersands to be escaped,
as part of URLs or otherwise.
A URL in plain text format, though, should not have ampersands
I knew that a URL in xHTML required ampersands to be escaped like that,
even in an . I did not know that a URL in standard (non-x)HTML
required that. Really? Okay.
But it’s confusing in part because an ERB template isn’t only used for
HTML. It can theoretically be used for creating any format, including
plain text, right? And someone using an ERB template to create (eg)
plain text is going to get tripped up there.
In my case, I wasn’t creating plain text, I was creating XML with an ERB
template. Which should be a perfectly fine thing to do, right? Sure, you
can use Builder if you want for XML, but you should be able to use an
ERB template too, right? But this definitely isn’t the first time I’ve
been confused by the proper amount of escaping of an ampersand in a
complicated data flow.
I’m still not exactly sure if I fixed my bug in the right part of my
somewhat complicated chain of data flow. I’d appreciate if you have any
insight, Hassan. Here’s what was going on:
An ERB template was generating XML. It took the result of a url_for
call, and put it through an XML-escaping routine, figuring that anything
that was being put in XML should be put through an XML escaping routine.
(Is this where I went wrong? Not sure.)
So we wound up with XML who’s source looked like
Is this correct or not? Not sure. Later in the program execution, this
XML gets converted to JSON, and the JSON winds up looking like:
This part was right, that is a proper JSON translation of the XML passed
in, right, it un-escaped the XML properly, put it in JSON.
variable, containing ‘/controller/action?foo=foo&bar=bar’. So far so
good, it got the right value from the JSON delivered to it.
Now, if that had been in HTML source for an , I guess the
browser would have ‘un-escaped’ that before making the HTTP request. But
(AJAX-style), it ended up submitting a GET to the HTTP server that
looked like this:
That wound up being caught by a mongrel-fronted Rails app, which did NOT
turn that into query parameters foo => foo, bar => bar properly, it did
weird things with that GET request.
So. At what point did that code go wrong? At the moment, I’ve fixed my
XML-generating ERB to not escape urls generated by url_for. But I’m
code that took a js variable containing
‘/controller/action?foo=foo&bar=bar’ and made a GET of that literal
string, instead of un-escaping it first, that went wrong? Or something
I’m very confused. And, since ERB can be used to generate all kinds of
formats, it still seems to me that the documentation should mention this
feature, which would have gotten me to my present state of confusion
several hours earlier—ah, but when I go look at the most recent rdoc
ActionView url_for, I see that it was there all along, my fault for
missing it: “When called from a view, url_for returns an HTML escaped
url. If you need an unescaped url, pass :escape => false in the
options.” So good on the rdoc after all. Still somewhat confused as to
whether I should be “double escaping” it in the XML or not.