401's, why have you forsaken me? (adventures in #webOS)
Mood: frustrated
Posted on 2011-08-28 12:33:00
Tags: essay palmpre programming
Words: 671

TL;DR - 401 errors are important! Handle them correctly!

I've started work on porting LJ for WebOS (LiveJournal client) to Enyo and the TouchPad...and it is not going well.

A little background: An XmlHttpRequest is a neat Javascript feature that let's you fetch web pages or other URLs in the background without requiring a page reload. (it's the "X" in "AJAX") Key to the whole app working is being able to access protected posts, and to do this, I have to use an XmlHttpRequest to fetch a post's webpage while adding "auth=digest" to it, saying I want to see the page as a logged-in user sees it. The dance continues with LJ returning a 401 Unauthorized HTTP error, but this has the necessary information to do another request with the proper authentication. (see the Digest authentication section of RFC 2617)

This is all a bit clumsy, but worked great in the existing LJ for WebOS. Last night I got to the point where I was actually trying to get posts in the new version. First up was developing in Chrome - one of the nicest part of the new webOS framework is that it's easy to test most things in Chrome instead of having to fire up the emulator and install it, etc. I noticed that when I tried this code for the first time, I got a bunch of popups in the browser asking for a username and password for various LJ sites. If I hit Cancel on all of them, things seemed to work - the code then saw the 401 error and proceeded to authenticate normally.

This seemed odd, to say the least, so I did a quick search which led me to this StackOverflow page (yay StackOverflow!), which says that's it's a known issue in Chrome and the only way to work around it doesn't work in my case (because I need to know what the headers on the 401 error are).

Well, that's pretty annoying, and seems clearly wrong to me - the user didn't go to this page, so why is she being asked for a username/password? I could see that you might want the option to do this in some cases, but the default should be off.

So I was already a bit irritated and, after a little bit more work, decided to try it in the webOS TouchPad emulator. I watched the logs scroll by as it got to the point that it did the first request for the post pages and then...nothing. Only when I quit the app by throwing the card away did I get some not-really-sensical error indications in the log.

I rebooted the emulator (as it seems to have a problem once you do too many HTTP requests or something), and the same thing happened. I was a bit at a loss - since I wasn't getting any of my log messages I couldn't see at all what was going on. Finally I fired up Wireshark to see the HTTP requests that the emulator was making to see if there was a clue there.

Much to my surprise, I saw it requesting the same pages over and over again! It would do a request, get back a 401 Unauthorized response, and then do a request again, seemingly trying to authenticate with an empty username and who knows what password.

I looked through my code and tried a few things to make sure that I wasn't causing this, but after some more searching I found a private thread confirming this behavior and that it was a bug.

*sigh* I can't make any more progress while this bug exists, and who knows when (or if?) it will be fixed in the OS. So, if anyone asks, this is why LJ for WebOS isn't on the TouchPad, and I guess I'll move on to other projects for now...

(this probably also mean that running the phone-sized version on the TouchPad won't work either, so...sorry about that. I don't have the heart to try it out right now.)

2 comments

Comment from unwiredben:
2011-08-28T13:15:49+00:00
Engineers were working on this bug just earlier this week. I got a test case together and submitted a test app for them, and we traced it down to oddness with how libcurl was hooked up to WebKit for apps. Basically, it has a callback for getting user/password which wasn't being handled right.

Fix should be in the next big OS release.

Comment from gregstoll:
2011-08-28T13:25:34+00:00
Ah, cool! That's quite a coincidence. Glad to hear it, and thanks for letting me know!

This backup was done by LJBackup.