On Fri, May 04, 2007 at 12:58:07PM -0700, Shannon -jj Behrens wrote: > On 5/4/07, Christoph Haas <[EMAIL PROTECTED]> wrote: > > I have created a URL using information from Routes using h.url_for(). > > Example: > > > > /start/page?page_nr=1&called=back > > > > Now I want to create a link to this URL with h.link_to. What I get is: > > > > <a href="/start/page?page_nr=1&called=back">foo</a> > > > > Apparently '&' is escaped to '&' which is what I obviously don't > > want. Of course in the case of h.link_to I could just create the > > <a href=...> link myself. But my actual code uses h.link_to_remote which > > is a bit more complicated and I'd like to use the webhelpers for it. > > > > I looked into the Webhelpers sources and saw that the URL is not escaped > > if it's callable(). What does that mean? And what would be the correct > > way to just pass the URL through? > > It's doing the right thing. Have a look at my blog post here: > > http://jjinux.blogspot.com/2006/03/html-escaping-s-in-urls-in-html.html
This is contrary to everything I have come across when doing CGI programming but anyway. If I understand you correctly then there is danger that browsers interpret http://localhost:5000/start/page?page_nr=1ß=back as http://localhost:5000/start/page?page_nr=1ß=back Very strange since '&' has always been the official parameter seperator for the GET method. But I know how well browsers do the wrong thing. I know that Perl's CGI module has moved to using ';' instead of '&' to avoid confusion. But I have never seen a concrete case where the ampersand breaks applications in browsers. Anyway, it appears like Routes understands this weird workaround and gives me my arguments back. So from... http://localhost:5000/start/page?page_nr=1&called=back ...I indeed get the parameters page_nr='1' and called='back'. Can somebody who knows Routes well confirm that it deliberately does this? Is it unescaping HTML like moving '&' back to '&' before parsing the line? My head is spinning... I wouldn't really expect this to work anywhere else. When I redirect to such an URL that is not handled by Routes then I would expect this to break. Too lazy to make a test case but a Perl CGI would probably return these variables: page_nr='1' and amp='' and called='back'. It would just work because Perl's CGI library accepts ';' in addition to '&'. This is likely a religious issue. But a word from the creators of this mess: [http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2] Quote: We recommend that HTTP server implementors, and in particular, CGI implementors support the use of ";" in place of "&" to save authors the trouble of escaping "&" characters in this manner. Is there any chance Routes and Webhelpers will use the semicolon in the future? Then I promise I'll stop yapping about it. ;) Christoph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
