Member Avatar for owltech

A few days ago I wracked my brain over an IE7 (only) problem that I thought everyone might like to know about. I was building and sending a URL that looked roughly like this:

www.somesite.com/program.php?param1=123&param2=234&copy_code=5

The program.php never received the third prarameter, because IE7 apparently tokenized the &copy into the copyright symbol ©. The HTML token for that symbol is [©]. Notice that in the URL above, there is no ending semicolon, however IE still managed to render the received URL as:

www.somesite.com/program.php?param1=123&param2=234©_code=5

which of course bombed the program. No other browser messed up the URL like that. Is this a bug in IE or feature? Sometimes it's hard to tell the difference.

Edited by owltech because: n/a
  • 3 Contributors
  • 4 Replies
  • 101 Views
  • 1 Month Discussion Span
  • Latest Post Latest Post by owltech

Dani AI

Generated

This thread documents a brittle interaction between HTML character-reference parsing and link generation in older Internet Explorer builds. first reported the symptom, suggested renaming the parameter, and confirmed it on a separate site. The practical, low-effort lesson is: avoid query parameter names that begin with common HTML entity names, or construct the final URL in a way that the HTML parser never gets a chance to mis-decode it.

Why this happens: named character references are defined by the HTML spec and are supposed to use a terminating semicolon; historically, some browsers accepted a few names without the semicolon and decoded them during HTML parsing. That decoding can change an attribute value before the browser forms the request. The spec and background on character references are here: WHATWG — named character references and MDN — character references / entities.

Practical fixes (ordered by reliability): rename parameters so they do not begin with entity names (the simplest fix, as suggested by ); build the href at runtime via DOM/JavaScript so the browser never parses that text as HTML entities; or use POST or a different parameter scheme when feasible. Example of setting the href at runtime:

var a = document.getElementById('mylink');
a.href = 'page.php?param1=' + encodeURIComponent(123) + '&archiveFlag=1';

Also keep using proper query builders and HTML escaping on the server (for example, http_build_query + htmlspecialchars in PHP) as a baseline practice; that helps XSS and general correctness even if it doesn’t eliminate every legacy parser quirk.

Troubleshooting tips: check the raw page source (not just the DOM inspector), capture the outgoing HTTP request with browser devtools or a proxy (Fiddler) and inspect server logs to see exactly what arrived. If the query string arriving at the server is already mangled, the issue happened client-side during HTML parsing and the safest fix is to change the parameter name or inject the link via script.

Member Avatar for Member #842639

I would think that it's just that IE7 has different compatability, so that it may interpret &copy as © while most browsers require the semicolon. Require is the key word here; it's no glitch. I would say it's not a bug or a feature, just an annoyance. So what I would do if I were you is just change the "copy" in your code to "cpy" or something else.

Edited by Member #842639 because: n/a
Member Avatar for owltech

Well, that's what I did (change the parameter name). But it sure took me a long time to find the "annoyance". Now, however, I have to make sure that in the future I don't pick a parameter name that could also be tokenized. Thanks for your thoughtful comment.

Member Avatar for Grindlay

Have just discovered this exact same problem with a client's site which was built and tested on FF4 and Chrome. In IE7-9, the URL :

page.php?id=1&copy_to_archive=1

as you say, IE sticks a copyright symbol in the URL.
I would say this is a bug as there is no semicolon following the &copy.
I have advised the client to use a "proper" browser.

More info here, many agreeing this is an IE bug :

http://nedbatchelder.com/blog/200812/accidental_html_entities_in_urls.html

Edited by Grindlay because: more info
Member Avatar for owltech

Thanks for everyone's response to this. -- owltech

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.