I'm blogging about this in the hope that it can help anyone else who happens to get stuck with this same issue.
On Friday I was caught out by a very 'interesting' bug in the mobile (WAP) internet browser of a Motorola SLVR L7 handset.
We were attempting to perform an HTTP redirect from one WAP site to another on the SLVR but were receiving a "404 Page Not Found" error message. When we looked at the URL that the phone was attempting to redirect to it was a combination of the first site with a bit of the query string of the second site tacked on the end:
First WAP site: http://www.first.com/Finder?type=holidays
Second WAP site: http://www.second.com/Holidays?title=Great Holiday+Location-Mar+2007
Result of redirect: http://www.firstsite.com/Finder-Mar+2007
We thought it might be the length of the URL, the number of parameters in the query string, or the fact that the sites were situated on different web servers. Mobile phone browsers are notorious for not fully supporting the HTTP stack and the Motorola SLVR was probably no exception. We resorted to slowly stripping out bits of the second URL hoping that at some point it would start to work.
We stripped all the parameters off the end of the second URL and that resulted in a successful redirection to the correct server. We then added the parameters back on and found that when we added the "title" parameter it failed. After a little more experimentation we discovered that the source of the problem was the word "Location" found in the value of the title parameter!
"Location" didn't work but "location" did...
Here's the reason why, take a look at this HTTP redirection header sent from the first server to the handset:
HTTP/1.x 302 Moved Temporarily
Date: XXXX
Server: XXXX
Location: http://www.second.com/Holidays?title=Great Holiday+Location-Mar+2007
...other HTTP headers...
The word "Location" occurs twice, once as a true HTTP header field and once as text in a URL.
Our guess is that the SLVR's browser code is a rather sloppy in how it detects and handles HTTP redirects and rather than looking for "Location" at the beginning of the line it matches the last one that it can find - hence the rather strange "-Mar+2007" on the end of the first URL!
Technorati Tags: Motorola, SLVR, WAP, HTTP, Redirect, Andrew Beacock
On Friday I was caught out by a very 'interesting' bug in the mobile (WAP) internet browser of a Motorola SLVR L7 handset.
We were attempting to perform an HTTP redirect from one WAP site to another on the SLVR but were receiving a "404 Page Not Found" error message. When we looked at the URL that the phone was attempting to redirect to it was a combination of the first site with a bit of the query string of the second site tacked on the end:
First WAP site: http://www.first.com/Finder?type=holidays
Second WAP site: http://www.second.com/Holidays?title=Great Holiday+Location-Mar+2007
Result of redirect: http://www.firstsite.com/Finder-Mar+2007
We thought it might be the length of the URL, the number of parameters in the query string, or the fact that the sites were situated on different web servers. Mobile phone browsers are notorious for not fully supporting the HTTP stack and the Motorola SLVR was probably no exception. We resorted to slowly stripping out bits of the second URL hoping that at some point it would start to work.
We stripped all the parameters off the end of the second URL and that resulted in a successful redirection to the correct server. We then added the parameters back on and found that when we added the "title" parameter it failed. After a little more experimentation we discovered that the source of the problem was the word "Location" found in the value of the title parameter!
"Location" didn't work but "location" did...
Here's the reason why, take a look at this HTTP redirection header sent from the first server to the handset:
HTTP/1.x 302 Moved Temporarily
Date: XXXX
Server: XXXX
Location: http://www.second.com/Holidays?title=Great Holiday+Location-Mar+2007
...other HTTP headers...
The word "Location" occurs twice, once as a true HTTP header field and once as text in a URL.
Our guess is that the SLVR's browser code is a rather sloppy in how it detects and handles HTTP redirects and rather than looking for "Location" at the beginning of the line it matches the last one that it can find - hence the rather strange "-Mar+2007" on the end of the first URL!
Technorati Tags: Motorola, SLVR, WAP, HTTP, Redirect, Andrew Beacock
Comments
It turned out, of course, that ...¤... from where the currentgroup param was specified in the URL was being turned into an international currency symbol - ¤, ¤ in HTML. IE was parsing it as a character entity in the URL, despite the lack of trailing semicolon...