This is a more technical post, and so if you aren’t interested in some nuances of browsers and Internet architecture, then you should pass on this one. It’s okay, you won’t hurt my feelings.
Man, we ran into a doozy today. We had one report from a user that people weren’t able to enter their moderated video chats. We weren’t sure that made any sense, and we couldn’t find any records of failure to enter the video chat in our error logs. It turns out we made two mistakes. First, we didn’t gather enough information. Second, we didn’t understand the errors we were getting back. Both, thankfully, are now fixed, but the journey was an interesting one.
First, let me give a little bit of background on our new architecture. We’ve just released our new call moderation stack at TokBox, and, to do so, we really sat down and thought through how to build this functionality in an Internet architecture appropriate approach. We came up with a really solid, RESTful API. The basic premise here is that all actions have a URI, and are a very specific contract between two endpoints (one being the user making the call, the second being our server). It was all very well tested on a Mac in both FireFox and Safari.
Here’s where the real journey begins. In RESTful fashion, we are defining the user’s role in a moderated chat by transitioning them from an “ASK” state where they are essentially knocking to get in, into a “PARTICIPANT” state where they have joined the call. The modify action uses the POST verb (though technically it should use the PUT verb, we weren’t confident in the Flex framework’s HTTPService class to handle this properly, and have instead limited ourselves to POST and GET), and then redirects to the user info action which returns the updated role, as well as any profile information about the user that might be pertinent to the video chat.
Now here is the gotcha. We use an HTTP 302 redirect to move between the actions. In all browsers not IE, it looks as if the 302 happens by first doing the verb of your choosing (in our case a POST), and then a GET to the redirected site. According to the spec as we read it, this is probably wrong. In fact, the redirect needs to ask the browser which verb to use in the HTTP/1.1 spec. Seems as if the HTTP/1.1 spec is either being misinterpreted, or the HTTP/1.0 spec is being maintained to enable backwards compatibility with how sites acted. Why did this cause us a problem? Because in IE7 & IE8, the 302 redirect does a POST (essentially repeats the original verb action). Our user info action was scoped as only accepting GET requests. The result… guest users couldn’t enter a moderated video chat from the IE family of browsers because the redirect fell into an error state, and didn’t return the proper response.
It took watching the TCPDump coming across the server across multiple browsers and API calls to figure this one out, but in the end we learned a very valuable lesson about how redirects work, making RESTful APIs work cross browser, and making sure we test across all combination of browsers and scenarios.