Monday, January 28, 2008

Bride.. a writer :).. congrats

finally her talent in writing is being rewarded. Bride (Ghada) has issued her first book out of her blog posts. for several years we have been enjoying reading her stories and her ironic accent. those are currently available in the new book that can be obtained through the book fair in Cairo.

Heads up to Ghada.. congrats

Wednesday, January 09, 2008

URL encoding special characters

i had a weird bug yesterday that consumed a bit of my time.
we have that we have an email that is sent to the user of one of our sites, with a link leading him back to his session (we add some key of the user to the link for that purpose). anyway.. we use a mail template.. a jsf page... all we need to do is to read that page (html generated for that jsf page) and replace some keywork with that parameter value
i had the link in the following format
http://server/servlet?target={user.key}
and i should replace that "{user.key}" with the actual value of the generated key.
this approach have been working fine for quite a while for that feature in several of our sites.
However, recently i was reported that the link was broken and leading to the error page.. as i investigated the matter i found that the link in the emails is
http://server/servlet?targetKKKKKK such that (KKKKKK is the key value)... the equal for some reason was missing.. pretty odd.

i checked the content of my template file.. the equal was there.. mmm..
after a lot of trials and debugging.. i was able to isolate the part where this problem was generated.
in reading the template we read it as an html resource on the web. not as a file. that's how to get the generated HTML and not the jsf code.

i tried http://server/templateURL.faces and voila... the problem was there..
for some reason the server dropped the equal character when generating the link. going little deeper i realized it is not the equal.. is it is the letter directly before the curly brace "{"... whatever u put there is being eliminated.

"Some systems can possibly modify these characters" that's was mentioned in some site describing a set of unsafe characters in URL encoding. maybe our system just decided to interpret the left curly brace as a back space..

my proposed solutions was either to use another stable character.. or to add another space and handle that when reading and parsing the template. (using "target=={" and when parsing the template i reverse it back if it is still there..)
it is a silly quick fix.. but it is the one that makes me backward compatible specially that i'm changing a code that is used by several of the sites.