What the Devil Is Going On?
Preloading the Interface
Using XMLHttpRequest Yourself
To get an idea of just what is going on, it’s a good idea to use XMLHttpRequest yourself. In this section, you’ll use it to create a little application of your own. Of course, you can skip this section if you’re not interested in a deep understanding, but it’s pretty cool stuff to play with anyway.
First, open up a directory on a website. You’ll need to access it via a proper domain, you see. Create the guide, and make sure your browser can see it. In that directory, place a text file, called Listing.txt, and put the exclamation “Horrible!” inside the file. Bear with me.
Finding XMLHttpRequest within the Gmail code
Sniffing the Network Traffic
So now that you understand how XMLHttpRequest works, you’re led to some further questions: What is being sent and received using the XMLHttpRequest functions, and what are the URLs? Once you know the answers to these questions, you can write your code to spoof these requests and then interface directly with the Gmail system. The rest of the book relies on this idea. To find out what Gmail is saying to the browser, use a new tool: the packet sniffer. This is a generic term for a range of applications that can listen to raw network traffic, display it on the screen, log in, analyze it, etc. You’re interested in watching what your browser is doing in the background: what it is sending, where it is sending it to, and then the replies it is getting.
Firing up TCP flow
Install TCP flow, and set it running inside a terminal window, monitoring port 80. On my machine, that means typing the following:
sudo cp flow -c port 80
As you can see from the figure and your screen, Tcpflow captures all of the traffic flowing backward and forward across Port 80 — all your web traffic, in other words. It shows the requests and the answers: headers, content, and all. So Tcpflow is perfect for the job. But there’s a snag. Open up Gmail, and let it sit there for a while.
You have seen this sort of URL before: Look back again at Listing A-3, after the second excised block of encrypted code. You can also guess that something happens to the cookie you set on the first page — it is being checked for something. Considering that those cookies do not contain anything but the time they were set, I am guessing that this step ensures that the connection is current and not the result of caching from someone’s browser. Instead, it’s to ensure a good, fresh session with Gmail on the browser application and the user himself. Or so I would guess.