Debugging web traffic

I had a curious little problem recently: in our new bug database, we couldn’t play video attachments within the browser (e.g. with the VLC plugin for Firefox, or Windows Media Player embedded in IE).  You could download the video as a file and play it – fine.  You could launch a media player as an external application and play it – fine.  But embedded in the browser window, it just didn’t work.  It’s also worth pointing out that our old bug database worked fine in all cases, so it didn’t seem to be a problem in the video playback/codec department.

I’ll put the solution at the end – the question you want to ask yourself is, how does a browser plugin behave differently from the browser saving the file to disk?


I started out by using Firebug to have a look at what was going on.  If you haven’t tried Firebug, I can’t recommend it highly enough – it allows you to do all kinds of powerful debugging of what’s going on in Firefox: way, way more than I’ll describe here.  For my problem, I just used the ‘Net’ tab – it shows you all the network requests made by the browser, allowing you to inspect both the request and the response, including all the headers.  This is pretty cool but I wasn’t able to spot the problem from this: the data appeared to be transferred correctly … weird!

Oh WordPress, you make so many requests for one page!

Oh WordPress, you make so many requests for one page!

I wondered whether the plugin was doing anything directly over the network and bypassing Firebug, and it was suggested to me that I try Wireshark.  It’s the first time I’ve used it, and it was impressive.  Within a minute or two I was inspecting all the traffic between my PC and the bug database.  It goes down to lower level protocols (you can see the raw network packets) but also provides a nice high-level (HTTP-level) summary.

Not sure what it all means, but it looks cool!

Not sure what it all means, but it looks cool!

Within seconds of looking at the data, I had the solution.  Turns out, the browser plugins don’t send the cookies that the browser does.  Our bug database was configured to require everyone to log in to view data, and without the cookies, it figured you weren’t logged in.  Rather than getting video data back, the plugin was getting an HTML page saying “Access Denied”!  Interestingly, when playing the video with the plugin, the browser firstly requests the data itself (until it gets some data back, it doesn’t even know it’s going to find a video at that URL), and of course gets it successfully.  The plugin then makes a fresh request to get the data itself.  Since Firebug was showing the first request, I foolishly thought I was looking at the data being transferred correctly (and wasted a lot of time looking into slight differences in the response headers, thinking they might cause the plugin to interpret the data incorrectly).

That’s it.  Not a big deal (we quickly reconfigured the bug database so as to allow anyone to view data without logging in), but I rather enjoyed the solution.  Most of all, I thought Firebug and Wireshark were both totally awesome – highly recommended 🙂

This entry was posted in Software development. Bookmark the permalink.

1 Response to Debugging web traffic

  1. Wireshark looks nice, I must try it too.

    To this specific problem, one other option would be enabling session initialization by sessionid passed in the url. (in PHP settings or ASP.Net settings). Then it wouldn’t require cookies to wake up the session, but the link to resource file would look like:


    In php there’s even a setting that modifies all urls on your response to include sessionids. I’m sure would be able to do the same.

Comments are closed.