New RIFERS blogs entries from Geert Bevin in category internet

Reindeer Arm Wrestling

Geert Bevin — Sat, 30 Dec 2006 19:22:02 +0100

Here's one for the holiday season ...

Error-less error handling : Apple Developer Connection

Geert Bevin — Wed, 27 Dec 2006 20:22:21 +0100

This has happened to me a few times already after I log into the Apple Developer Connection site. I thought I'd share this moment of wonderful communication with a website user:

Embedding images inside the source of a HTML page

Geert Bevin — Mon, 11 Apr 2005 22:55:45 +0200

My friend JR pointed me to this trick which is detailed in RFC 2557

It turns out that by using a special data: URL scheme you are able to embed any mime data inside a HTML page, the format is as follows:

data:<mimetype>;base64,<data>

<mimetype> needs to be replaced by the mime-type of your data (image/png for instance) and
<data> is the base64 encoded string of the actual bytes of the file.

For instance, look at the source of the image below, or simply click on it and look at the URL in your browser's location bar.

This technique works in Firefox, Safari, Konqueror and Opera. I think it has great potential! Sadly I can't get it to work in Internet Explorer.
I already can imagine very useful applications for this: captcha images, image uploads in blog posts, ...

Internet Explorer doesn't even handle redirects correctly!

Geert Bevin — Fri, 01 Oct 2004 08:34:14 +0200

We got complaints from users of Bamboo that after posting a new forum message, they weren't brought to their recently posted message but to the first message in the thread instead. We were completely baffled since it worked perfectly in FireFox, and all we did was redirect to:

/forum/list/messages?topicid=1159&offset=75#goto_6362

Nothing extraordinary there, right?

Well, that's forgetting about Internet Explorer's ability to introduce bugs in even the most trivial areas. Instead of providing these parameters to the web application:

topicid=1159
offset=75

It manages to not strip off the anchor and provides these parameters instead:

topicid=1159
offset=75#goto_6362

I thus inded up handling this directly in RIFE. When the sendRedirect(String url) method is called, it checks for the user agent and if it's Internet Explorer and the URL contains an anchor, it does a refresh instead of a redirect. This shows a white screen to Internet Explorer users for a small moment, but it's the only way we've found around this bug.

Again, Microsoft was able to suck up about 4 hours of my time, without me getting paid anything. It's about time people that start to talk about Windows and Internet Explorer not only being less productive than MacOSX or Linux, but even people that don't use the applications themselves are forced to handle the stupidities that lurk inside.

Weird browser behaviour with anchors and redirects

Geert Bevin — Mon, 05 Jul 2004 16:11:33 +0200

I just noticed today that when you're receive an like this at the server-side:

/reply/message#lastmessage

and you redirect to this URL with a 302 'Permanently moved' response:

/list/messages?topicid=1152&offset=0

Some browsers automatically add the #lastmessage anchor after the URL. Both Mozilla and Opera do this, but Konqueror doesn't.

Very weird behaviour!

It seems impossible for URL character encoding to be correct

Geert Bevin — Mon, 21 Jun 2004 11:40:48 +0200

When I finally thought I had covered all character encoding problems, it finally turns out that it's impossible to correctly handle encoded international characters in URLs.

It's common knowledge that URLs are restricted to only a very restricted sub-set of the US-ASCII character set. Luckily though, the HTTP Specification provides an 'escape' mechanism for other characters. This makes it possible to include any possible character in an URL by encoding it first. Every byte in the character will be represented by a %HH string, where HH are hexadecimal characters. However there seems to be no specification that standardizes how these encoded characters need to be interpreted when they arrive in an URL at a server. Actually, they could come from characters in any possible encoding and without knowing which character set they belong to, the bytes are almost certain to be wrongly interpreted. Most servers seems to default to the ISO-8859-1 encoding, which might be workable in some situations, however in this modern internet age we should able to use any Unicode character, no?

Has anybody found a good solution for this problem? As it stands now, it makes REST (Representational State Transfer) impossible since the URL is not able to carry around data correctly.

Discovered Browser Cam

Geert Bevin — Wed, 10 Mar 2004 01:14:18 +0100

Maybe this is common knowledge and everybody uses it already, but I recently discovered and started using Browser Cam. It turns out to be extremely convenient to check all your target browsers at once while creating a new web design.

Maybe it might be helpful for someone else too.

Rarely lauched so much with a site

Geert Bevin — Mon, 08 Dec 2003 20:39:24 +0100

Check this out: http://www.extremeironing.com