iPhone Safari and XmlHttpRequest Authorization-Headers

Lately I came across an odd phenomenon regarding the iPhone OS (3.1) Safari and web-sites that make use of JavaScript to set XmlHttpRequest-Headers, like for ETags or for authorization. I’ve analyzed the (mobile) Safari’s behavior, tried to find possible mistakes within my JavaScript/jQuery code, searched the internet and even called Apple’s Technical Support (Germany) for more information on that problem. Let me first of all begin by describing the actual occurrence:

I’ve been working on a web-site that used the jQuery framework to render content on the client side and get information from its back-end, via XmlHttpRequests. The whole built-up worked just fine of every modern, popular browser available in the market – like the Firefox, Internet Explorer or Safari (on the Mac platform). Now, I had to test the site and make it workable on the iPhone-plattform as well. The site itself uses OAuth as authentication method and provides the information within a HTTP-header named “Authorization”. The theory is pretty plain: The back-end receives a request, checks for this header and responses accordingly.

However, iPhone’s Safari didn’t behave like the other browsers did. For whatever reason, the XHR was sent to the back-end, including every header that was set on the JavaScript side – except the “Authorization”-header. First, I though that Safari maybe could not handle the parameters of this header, but when I just renamed the setRequestHeader-argument to “Auth”, it worked. It simply just worked.

This happening made me search for other users experiencing this problem, unfortunately there doesn’t really seem to be many users testing JavaScript-sites on their iPhone – to be more precise, I did not find one result on Google that describes the problem I’m experiencing. I though, “Oh well, why not call Apple’s Technical Support?” – bad mistake. I got connected to a very annoyed and stroppy telephone-support which tried to convince me, that the iPhone’s Safari yet does not support Java. When I repeated myself by saying “It’s about JavaScript“, he didn’t really make the impression to understand the difference. I told him what the actual scenario was and all I got as answer was “Fill out the Feedback form on Apple’s site”. This made me a bit angry, because I more and more got the feeling of him trying to simply get rid of me. I asked for someone who is more technically involved into the whole iPhone stuff and he answered with “You’re already calling the most-advanced technical support – there’s no way to go further!”. At this point total disappointment overcame me and the only thing I thought of saying before I would hang-up the phone was “FAIL!” – luckily I was behaving more polite than the support-guy himself. Eh.

The end of the story is, that I (once again) wrote a report via Apple’s Feedback form (which from my impression is saving the submitted content to /dev/null) and implemented a workaround for myself by renaming the “Authorization”-header to “Auth”. Yet again a scenario in which I’m feeling like talking to a wall of bricks and have no possibility to get any information regarding my problem or maybe even correct this sort of bug. I think, this is the other side of closed-source software.

About this entry

You’re currently reading “iPhone Safari and XmlHttpRequest Authorization-Headers”

Published:
10.23.09 / 9pm
Category:
Life itself, Mac and stuff ..., World Wide Web
Tags:
, , , , , , , , ,
Read it:
On your mobile device.