Skip to main content

HTML: Escaping &'s in URLs in HTML

Warning: Failure to ignore the following validation warning may result in lost productivity!
Concerning Ampersands (&'s) in URLs, the following is what I wrote in the Aquarium documentation:

The short answer is, if you have a URL with more than one parameter, you should wrap it with $htmlent when you embed it in HTML if you want to pass DTD validation. If you don't care, then it really won't matter. What follows is an explanation of why I can't make it any easier on you.
  1. You must escape &'s in URLs in order to pass DTD validation. Per the spec, a browser could look at http://a.com/?a=b©=2 and interpret the ©= as part of value of the a variable instead of a new variable named copy; because © is an HTML entity.

  2. To handle #1, Aquarium use to escape the &'s in every URL automatically.

  3. However, #2 broke redirects if you redirected to a URL with more than one parameter. I so rarely did this, that I didn't know about the bug for a good year.

  4. To fix the bug in #3, we came up with a scheme to always escape &'s but deal with the redirect case specially. Now imagine if you create a HTML link whose URL has a parameter named referrer that is set to your current URL, which itself happens to have two parameters. When the user clicks on the link, Aquarium now has a GET parameter named referrer that is a URL. The programmer can use that URL directly in HTML (in which case the &'s must be escaped) or he might redirect to it (in which case the &'s must not be escaped). The programmer is never going to remember whether the URL is already escaped (per #3, it already is) and whether he needs to escape it for a link or unescape it for a redirect. His brain would core dump.
    When it comes to escaping things, a good general rule is to escape things at the last possible moment. By violating this rule, bad things were happening.
  5. We could force engineers to wrap every URL in HTML with htmlent, but that would suck. Too much existing code doesn't.

  6. Browsers are smart, and most of the time, if you don't escape the &'s, the browser won't get confused. In fact, you can't generate a URL like http://a.com/?a=b©=2 with Aquarium anyway, because the ; will get urlencoded to %3B. Hence, it's not possible to get Aquarium to generate a URL that would confuse the browser. Programmers who are worried about passing DTD validation and have a URL with more than one parameter will just have to use $htmlent. That's better than forcing every programmer to think about the problem every time he generates a URL since, practically speaking, the warning is pedantic.

Comments

Anonymous said…
It's worth noting that failing to escape ampersands (in URLs or anywhere else) precludes you from publishing XHTML, as most browsers and other clients use a validating parser, which will choke on the first '&name=bob' in a URL. And you won't have any sort of notification of this problem with your site logged on the server, just a user with a confusing, ugly error message where your page should be.

I suppose serving any XHTML as text/html is a "works in enough browsers" means of avoiding the validating parser, but if you don't want to go through the pain of making valid XML, I strongly recommend using HTML4. By not using invalid XHTML, you don't have to worry about redoing all your XHTML pages if you ever change servers (in the case that the new server uses one of the other valid content-types for XHTML).
jjinux said…
DHTML Utopia: Modern Web Design Using JavaScript & DOM made a pretty strong case against using XHTML. For those that care about this problem, they'll have to use $htmlent. That is, it's possible to do THE RIGHT THING. It's just frustrating that I can't make doing the right thing much easier :-/
Anonymous said…
Sounds like '&' is a bad choice anyway if it can be confused with an SGML element. Quote from http://www.w3.org/TR/html401/appendix/notes.html#h-B.2.2

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.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and jabber.org. Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p