T-Online wants to escape .. and escape ..

When clicking items on <http://shopping.t-online.de/> they are supposed to take you to the vendor's site in a new window.

The site uses a very complicated function to open popup windows… <http://www.t-online.de/functions.js>

The problem seems to be that they pass you through a "counter" which receives the actual destination URL as an argument. When certain characters are used as part of an address it is normal to encode them in a specific way, called "escaping". The opposite process, translating the escaped characters back to normal is called "unescaping".

In the source code of the page the actual target URL is already escaped but they still use the JavaScript function escape() on it, in effect encoding the characters twice:

javascript:oW('http://count.shopping.t-online.de/RE?ID=1939036&CID=1744278&GID=&#039; + TI + '&URL=' + escape('http%3A%2F%2Fwww.jako-o.de%2Findex1.mb1%3Fdeeplink%3D%2Fprodukt%2Fde%2Fprodukt_detail.mb1%26set%3D4%26detail%3Don%26k_id%3D38101%26s_id%3D5000256%26g_id%3D5000377%26p_id%3D2275%26back_sid%3D5000256%26back_gid%3D5000377%26mb_v301_s%3D1%26mb_v301_g%3D20%26lang%3Dde%26fag%3Dd%26ref_id%3D9136'),'ef');

The other browsers ignore this. Compare the contents of the message box if you put this address into Opera and IE:


Opera escapes the string the way I would expect while IE seems to check whether the string already is escaped and actually does the equivalent of first unescaping and then escaping it.

The never ending mysteries of IE compatibility..

When the double-escaped address is sent to the server, it is not quite recognised and the server just forwards you back to the main page.

Besides IE's unexpected behaviour, it seems like the client-side and server-side programmers at T-Online do not communicate. Characters in an URI needs to be escaped server-side OR client-side, there is no point in doing both.

2 thoughts on “T-Online wants to escape .. and escape ..

  1. That kind of "helping hand" is what makes it hard learning new languages in the first place. At least in my case things like PHP's magic_quotes_gpc caused me an entire days extra work in my studies because I couldn't figure out why forms automatically were escaping this and that.

    Actually I wrote a function to take care of it without knowing about magic_quotes_gpc and then discovered it about a week before the project was due. Since I was smart enough (or lucky, whichever way you prefer to look at it) to put all formatting from forms in a function, I could rewrite the code to something cleaner.

    (Btw, we got an A on the project in case you wondered 😉 )

  2. You are putting the escaped string into the address bar. In the same way as the server will then decode this, IE will decode any encoding itself if the target is the local page (which it is).

    See for yourself. Put this in the address bar:
    %22 is " quotes. IE realises that the javascript: protocol is a local address, so it decodes it. Opera does not.

    I believe this relates to the way that IE treats invalid address characters in a link:
    <a href="try this.html">test</a>
    This is automatically encoded (<space> -> %20). I think it does the same with javascript: protocol links, even though the javascript: protocol does not need to be encoded, as spaces are permitted. Because it is now encoded, it needs to unencode it again to use it.

    I think it applies the same rule to any addresses you put in the address bar, as it assumes that it <drl>screwed them up encoded them that way in the first place.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s