After noticing that the caching in iPad Safari seemed a little funky, I made an effort to decipher some of the logic used by the browser cache. I didn’t get very far, but in the process I figured out how to route my iPad HTTP traffic through a web debugger on my laptop. It turns out it was very easy to do (although I’m sure there is a more complicated way to go about it).
What follows is a simple step-by-step for connecting your iPad to an HTTP debugging proxy. The main requirement is that your desktop/laptop and iPad be on the same wireless network. Then it’s just a matter of telling your iPad to use your desktop as an HTTP proxy.
I’m going to walk through how to do this on a Mac with the highly recommended HTTP proxy app Charles, but the same basic steps should also work for a Windows HTTP debugger such as Fiddler. (Update: Fiddler users, see Eric Lawrence’s comment below.) Additionally, the steps are the same for connecting your iPhone or iPod Touch.
1. Get your system IP address for your desktop
The easiest way to do this on a Mac is to Spotlight your way to the “Network Utility” app. Make sure you’re on your Wi-Fi network and take note of the IP address. This is your desktop’s local IP.
2. Tell your iPad about your desktop IP
On your iPad, go to Settings > Wi-Fi and click the arrow next your Wi-Fi connection. Under “HTTP Proxy”, select the Manual button and enter your desktop’s IP address in the Server field. Then enter “8888″ in the Port field. Close out.
3. Configure Charles
Open Charles and select Proxy > Proxy Settings. Under the Proxies tab, make sure the HTTP proxy value is set to 8888. Then click the “Mac OS X” tab and check “Enable Mac OS X Proxy” and “Use HTTP Proxy”. Click OK.
4. Start capturing HTTP traffic
Click the Record button in Charles and then load a web page in iPad Safari. You should see the following alert asking you if you want to allow your iPad to connect to Charles. Select “Allow”.
Now all of your HTTP traffic in iPad Safari should be recorded by Charles.
When you’re finished doing all of your fun HTTP debugging, don’t forget to turn off the HTTP proxy in the Wi-Fi settings of your iPad.
Steve Souders
April 14th, 2010
This is incredibly valuable. I haven’t tried it, but am tucking this away for the next time I want to observe HTTP traffic on my mobile device. Remember that proxies can change browser behavior (# of connections, maybe even gzip), so keep that in mind.
Ryan Witt
April 14th, 2010
Excellent work! If this ends up affecting behavior too much, what I’ve done in the past is turn on routing on a Linux/FreeBSD box, set the iPad default gateway to the box’s IP and use tcpdump to capture the traffic so it can be viewed in wireshark.
Andy Davies
April 14th, 2010
Charles is a great tool but as Steve mentions it can influence behaviour – we use it regularly and notice it can influence performance at the client, we had some really strange flash behaviour with it (not that it will happen with the iPad of course)
Andreas
April 14th, 2010
I’d like to add that charles debugging proxy is excellent in web development as well. That goes for ajax as well as to analyze traffic/headers and general http behavior.
Rob Flaherty
April 15th, 2010
All,
Thanks very much for the comments and the warnings about the proxy potentially interfering with the browser’s behavior.
Tom Rankin
April 15th, 2010
This is a great technique, I’ve been using it for a while to debug iPhone traffic using Fiddler2 on the PC. This is also a great way to reverse engineer traffic from other iPhone apps that communicate back to their servers over http because that traffic will end up going over the proxy as well.
Eric Lawrence
April 22nd, 2010
Thanks for the Fiddler mention! The only configuration you need to do for Fiddler is tick the “Allow Remote Computers to Connect” inside Tools > Fiddler Options > Connections. Restart Fiddler and you’re good to go!
Rob Flaherty
April 26th, 2010
@Eric
Thanks for the info (and thanks for Fiddler)! I updated the post with a link to your comment.
Ben
July 18th, 2010
I did some experiments in the same way on my Mac with TcpCatcher (default proxy port is 8200). The tool is free and allows packets modification on the fly