Mobile Networking · Watching Traffic · Lesson 3 of 4

Reading HTTP Requests

Learn to read the parts of an HTTP request and the headers that matter most.

Anatomy of a request

Every time an app fetches data, it sends an HTTP request. Once a proxy decrypts it, a request is plain, readable text. The first line has three parts:

• a method, the action the app wants
• a target, the path on the server
• the protocol version, like HTTP/1.1

The two methods you'll see most are GET and POST. GET asks for something and normally has no body. Anything it sends travels in the address after a question mark, in the query string. The weather app's GET /v1/forecast?city=... worked this way.

POST sends data to the server inside the request body, which comes after the headers and a blank line. Forms, uploads and logins usually use POST. A POST to analytics.tracker.example/collect means the app is sending data off to a tracking service.

Newer versions, HTTP/2 and HTTP/3, pack the same parts into a compact binary form. Proxies still show them to you in this readable layout.

Headers that identify you

Below the first line come the headers. Each one is a name, a colon and a value, on its own line. They carry details about the request. Three matter most when you're checking an app:

• User-Agent names the app or browser, often with its version and the phone's system version.
• Cookie sends back small values a server stored earlier, often a session ID that keeps you logged in.
• Authorization proves who you are, usually with a bearer token after the word Bearer.

A bearer token works like a ticket. Whoever holds it can use it. If someone copies your token or session cookie, they can often act as you until it expires, without ever knowing your password.

That's why the lab redacted the token, and why you should do the same. Before you share a proxy capture with a teammate or in a bug report, blank out the Authorization and Cookie values. Treat them like passwords.