Today, while I was working on the URL encoding for the recently released Facebook-style Links module, I realized a bug with Link Attachments feature on Facebook. Before I explain, let us reproduce it:

Try to attach the following link on Facebook: http://google.com/search?q=blenders%26pride. This URL actually queries Google for ‘blenders&pride’. Facebook converts/encodes the above URL to http://google.com/search?q=blenders&pride which is not the same as above and queries Google for just ‘blenders’.

So, why Facebook does this? Probably Facebook tries to encode the URL to remove the characters which are not allowed by RFC 3986 and replaces them with their percent encoding. But there are certain characters which should not be encoded, such as ‘/’, ‘?’, ‘#’, ‘@’ which are the reserved characters and used as delimiters in the URL. So, it decodes these characters and converts their encoding to the original character which gives rise to the problem. Let us see an example:

‘http://google.com/search?q= %2B‘ is first encoded to replace unwanted character with their percent encoding, turns into ‘http%3A%2F%2Fgoogle.com%2Fsearch%3Fq%3D%20%2B’. (Note: I assume that already encoded characters are not encoded again in order to reproduce the bug, i.e.%2B does not gets converted to %252B). Then, the reserved characters (/,:,?,=,@,+) must be decoded again, therefore it gets converted to ‘http://google.com/search?q=%20+‘ which as we see is not the same. It ideally should have been ‘http://google.com/search?q=%20%2B’.

I have already reported it in the bugs on Facebook. I will like to hear your views on URL encoding. Do you consider this as bug? Why does such URLs are not properly formatted at source making lives of developers difficult? Why does URLs with spaces and other disallowed characters exists?

Enjoy.

Related Resources:

• http://en.wikipedia.org/wiki/Percent-encoding