The other day while trying to view the latest trailers on the Internet Movie Database (IMDB), I encountered the following error:
I’d played videos on IMDB in just the recent past, and I was using the same system and browser. It’s always frustrating to not get what you want when you have a few minutes of spare time to goof-off, so at first I just tried again.
Same error.
I tried a different video. Same error.
Videos on other websites such as YouTube or Vimeo hadn’t show any such errors before, and I use them regularly. I know that Firefox 52 ESR is capable of playing videos via HTML5. I even have Adobe Flash installed. But IMDB wasn’t trying to use it.
Firefox lets you install a mind-bogging number of add-ons, many of which can cause weird website issues. I’m used to having quirky issues because I use extensions such as NoScript, HTTPSEverywhere, Greasemonkey, Classic Theme Restorer and many others that all have their own configurations and settings that can be quite extensive. Anything that changes the way a request is sent, filters responses, or tweaks the HTML/CSS before rendering has the potential to throw things out-of-whack.
(Add to that that Firefox, as mature as it is, fails various smoke tests. Complex standards are hard, especially when you’re dealing with cross-platform applications).
But back to the problem. This isn’t about how I fixed the issue, or what caused it. Rather, it’s about how I troubleshot the issue and eventually realized what the cause was, in order to fix it.
To start with of course the standard place to turn is a Google search. My searches on “IMDB trailers won’t play” and variations, as well as the specific error message I got, confirmed the issue happens to other people, but not frequently. Most people who posts about it were using Ubuntu, usually with a native Linux browser. I didn’t find any obvious solutions nor a common thread for the issue. I also searched IMDB’s own website but nothing useful turned up.
I verified my NoScript extension was allowing scripts for IMDB, because that’s a common reason for getting errors and non-functional pages on websites. But NoScript was configured to allow scripts for both IMDB and associated websites. And as mentioned, I remembered recently playing videos on IMDB, so it seemed unlikely NoScript was the cause.
I also tried opening up a Private Browsing window to see if perhaps the issue was related to cookies, my login state or something similar. This didn’t make any difference, but that told me it was unlikely to be related to anything specific to that browsing session. And since the IMDB website was otherwise responsive and other websites worked fine, it didn’t seem likely to be some sort of outage or server issues on their end (not that it can’t happen).
At this point, I’d only done the most basic and preliminary of troubleshooting, the sort of things you do to quickly solve a problem which won’t take more than 5-15 minutes maybe. Now I’d have to either give up, or delve into much more complex steps. Good thing I know what I’m doing! So I fired up the useful Tamper Data add-on for Firefox. It lets you view all the HTTP(S) requests and responses for the browser, and when enabled you can intercept a request initiated on your end in order to alter the values submitted. I most commonly use it to see the full HTTP(S) conversations though.
(NOTE: You could use the built-in Firefox Web Console in order to view this traffic. I tend to default to Tamper Data out of habit and because sometimes I’ll actually need to modify values).
Reviewing the requests for the IMDB page when I clicked on the icon to start a trailer playing, I was able to approximate where the requests were which led to the error. I used the hostname portions of URLs to determine which requests related to IMDB and which were from other pages. And by looking at the requests I could try copying the URL of several and open them in a new tab. Both to see what errors I would get and to eliminate interference from other page elements such as frames and scripts. By doing this I got a more condensed version of the video player portion of the trailers page.
(All of this was to try and find the actual URL of the video file, which would have to be in a format playable via an HTML5 standard. It couldn’t be Flash, QuickTime, WMV or other proprietary standards. It had to be in OGG or MP4 container format. If I could find the raw file then maybe I’d be able to actually view it, or get a better idea of what actual error was occurring.)
I viewed the source of the page, to see what was being called and what scripts were in play. As you can see, the script object for the player uses a number of URL’s to load CSS, SWF, the player skin, and icons. There isn’t going to be a handy “Here’s the raw video file!” link just waving it’s arms at you, but it’s in there.
I had to copy the stream of requests from TamperData into a text file in order to more easily page through them and search for the specific request that led to the failure.
Each entry in the list of sessions is actually all the HTTP protocol request headers and response headers (if any), along with date-time stamps. Again, you can get this same thing from the Web Console in Firefox (Chrome and other browsers have similar built-in tools or available add-ons). I copied these set of requests into a separate text file for easier searching and scanning.
It took a little time to find the right request. Requests mixed in from other webpages and add-ons I had open added to the pile to sort through. I had to rely on the date-time stamps to find the target, but I’d anticipated the need for that by making sure several seconds passed between when the trailer player loaded, and when I actually hit the play button. That pause was detectable in the log as a multi-second difference between two requests.
Once I found a likely entry, I could view the actual request and response. This was where I found why the video wouldn’t play: The remote server returned a “403 Access Denied” error:
But why would that happen? I was logged in. These aren’t paid content. And I would expect that if IMDB had a major issue with their site they’d mention it. During my Google searches earlier, I’d found IMDB’s official page on having issues with trailers not playing. The advise was typical but it did mention that sometimes IMDB would have “network problems” and you might just need to come back later.
Now. Is that what happened? Well, there was a network problem… but it wasn’t IMDB’s fault. It was mine.
I loaded the URL directly, and got a nice XML error with the 403. I removed some parameters, and got a different error saying that a key was needed to play. I thought at first it was possible a server admin hadn’t installed an API key correctly, or a media license or some similar issue.
But I looked back more carefully at the URL, the request headers and the response headers from TamperData. Something hit me: The referrer address was HTTP, but the URL requested was HTTPS. And sometimes, that’s not what you want.
I use a Firefox Addon called HTTPSEverywhere, first published by the EFF. HTTPSEverywhere’s purpose is to make sure that whenever you visit a website that is known to support HTTPS, your browser uses it, even if that’s not the default. Most major sites let you use HTTPS but will re-direct the next request to the HTTP side.
Not all sites quite fully work with it. Like IMDB. The server the video file lived on could do HTTPS, but it wasn’t configured completely. The developers probably didn’t test for it. IMDB isn’t really a site with sensitive data. If you login, your credentials will be sent via HTTPS. If you provide payment information for IMDBPro, obviously that gets encrypted. But why bother to encrypt a trailer?
I checked my HTTPSEverywhere settings, and sure enough a rule called “IMDB (partial)” was enabled. I disabled the rule and the video played fine.
Lessons learned: In the end, the problem was of my own making. And solving it actually only required checking a box off. Perhaps if I’d recalled that rule was enabled, or if I’d remembered how sometimes HTTPSEverywhere causes weird behavior, I would have solved the issue faster. But I’m the sort of person who enjoys tearing into the actual systems, protocols and data to root-out what’s going on. Sometimes that’s my first thought, and I waste time when I could have just spent a few minutes thinking carefully or remembering potential conflicts.
At least I got to make a post about it. :)
