Using a Web Proxy to Test and Debug the JW Player or: Why Charles is our Best Friend

Update: JW7 is now available. Check it out here.

One of the tools that we’ve come to rely on quite heavily over the past several years is a web proxy. Frequently, we see support requests come in where a publisher has misconfigured the player by pointing it at a video file or skin which does not exist on their server. Using a web proxy, it’s possible to log all requests, making it quite easy to see when requests are failing because the file they’re trying to load isn’t there. Additionally, since some web proxies allow you to modify requests, publishers can test out new player versions, plugins, or skins without modifying any code on their live site. In this blog post, we’ll show you how to use a web proxy called Charles to help you debug your current JW Player configuration and test out new configurations.

How a Web Proxy Works

When you’re running a web proxy, it acts as a middleman between your web browser and the website you’re trying to access. Normally, your web browser makes requests directly to a website. When a web proxy is running, it acts an intermediary for all of your traffic, receiving all requests and then dispatching to the website as needed. This means that it’s able to log requests, modify them, or allow them to pass through normally – and all of this occurs transparently to your web browser.

Setting up a Web Proxy

Getting and setting up a basic web proxy is easy! Browsers like Chrome, Safari, and Opera have developer tools with a basic proxy built in. For Firefox, there’s the popular Firebug extension. These allow you to monitor outbound requests and see what your server is returning for each request.

Around the office though, we use Charles Proxy. Rather than simply logging requests, it allows you to modify them as well – pointing one network location to another, or pointing network files to files on disk. Additionally, because Charles exposes its proxy to the general network, it’s possible to use a desktop running Charles as a web proxy for devices like the iPhone, iPad, and Android handsets.

A Few Examples

There are a few common cases where a web proxy is exceptionally useful. These examples only scratch the surface of the power of a web proxy, but they should get you well on your way.

Inspecting Your Web Browser Traffic

The most widely used feature of a web proxy is it’s ability to monitor web traffic and it’s the basis for all of the other examples that we’ll talk about in this post. Once you’ve successfully installed Charles, go ahead and launch the application. You’ll see a screen that looks like this:

Once the application has finished loading, open up your web browser and navigate to a page where you’d like to monitor the web traffic, like so:

As your web page loads, you’ll see the request log growing in Charles. Clicking on any individual entry will give you detailed information on the file loading including HTTP response code, size, and time to load:

Validating Your File Paths

The example below shows a standard player configuration using a player with a video, thumbnail, and skin. After opening the web page containing this player in our web browser, we found that the thumbnail image wasn’t appearing. Next, we launched Charles, cleared our web browser’s cache, and reloaded the page in our web browser. It turns out that the file location we used for the thumbnail doesn’t exist! To indicate that the file is missing, Charles placed a red circle with a question mark next to the filename and listed “404 Not Found” in the response code field, as demonstrated in the highlighted entry below:

You’ll want to be sure to check the entire request log for 404s – it’s pretty common for things like crossdomain policy files to be missing as well.

Confirming that the GAPro Plugins is Tracking Correctly

When you first start using the GAPro plugin, the process of testing your configuration and waiting for new data to appear is quite time consuming, as it may take up to 24 hours for Google to process the new event data. Rather than wait, simply boot up Charles, navigate your web browser to a page containing a JW Player configured to use the GA Pro plugin, and look for a call to Google Analytics in Charles, like so:

Testing Your Site with a New Player Version

We always recommend testing out our new player versions with your site’s configuration before upgrading. Charles provides a powerful tool, called Map Remote which will help you accomplish this without any special testing pages for your site. First, upload the new player.swf and player.js files to your site, but don’t overwrite your existing player. Next, open Charles and point your web browser to a page that currently contains a JW Player, and that you’d like to test with your new JW Player. Look through the requests in Charles to find your player in the list of requests and right click it. You’ll see a menu like this:

Select “Map Remote”. A dialog box will open. The original address will automatically be populated in the top section, labeled “Map From”. Now, enter the address for the player you’re trying to test in the box labeled “Map To”, like so:

Finally, if you clear your web browser cache and reload the page in your web browser, you’ll only see a request to the new file, with a note indicating “Mapped from remote URL: “.

Assuming your configuration worked, you can go ahead and replace your original player.swf and jwplayer.js with the new player or update your site configuration to use the new player. Be sure to close Charles when you’re done testing, otherwise you might continue to map to a file that doesn’t exist!

Note – In addition to testing out a new player, you might also want to test out an entirely new player configuration. Rather than using “Map Remote” as you would when testing a new player, you’ll want to use “Map Local”, which allows you to point to a file on your file system. Thus, to test out a new configuration, simply download a copy of the page you’d like to test onto your desktop, make the changes to your embed code locally, and then point the remote address with that file to the version on your desktop. Everything will remain the same on your live site, but you’ll be able to test your new configuration locally with all of the images, scripts, and advertising loading as they would for your viewers.

Configuring iOS to Use Charles

You can also configure your iPhone and iPad to use Charles for testing. First and foremost, it’s important to make sure that your iOS device and your computer are using the same network (wifi or wired) – none of this will work otherwise. Once you’ve verified this, go ahead and fire up Charles. After Charles has finished starting up, you’ll need to figure out your computer’s network IP address (instructions are readily available for Windows and Mac). In this example, the IP address of the computer is 192.168.0.116. Next, open up the network configuration on your iOS device and set the HTTP Proxy to your IP address on port 8888, as demonstrated in the highlighted box below:

The next time you open up Safari on your device and navigate to a page, Charles will prompt you with the following message:

Simply click “Allow”, and all of your iOS device requests will be logged and routed through Charles just like your normal browser requests.

Limitations of Web Proxies

Web proxies work great for many player configurations, but they have certain limitations as well. For example, Adobe’s RTMP streaming protocol uses a lower level network connection, thus bypassing most proxies. If you’re using RTMP, you can still use a proxy to confirm that your thumbnails, plugins, and skins are properly configured, but there’s no way to ensure you’ve pointed to the correct video assets.

Hopefully you’ve now got a good grasp on what a web proxy is conceptually and how it can help you setup, configure, and troubleshoot your JW Player. As you use web proxies more, you’ll continue to find new and amazing possibilities. Please be sure to share your discoveries in the comments!