Capturing HTTP with Wireshark

What you are looking at#

Wireshark records the frames arriving at and leaving a network interface and decodes them. Its window has three panes, and knowing which is which turns the tool from intimidating to obvious:

The detail pane is where the exam lives. It shows one packet as a stack of layers, outermost first, and that stack is the protocol stack you have been learning:

Frame          — what the capture tool recorded
Ethernet II    — link layer:    MAC addresses
Internet Protocol Version 4  — network layer: IP addresses
Transmission Control Protocol — transport layer: ports, sequence numbers
Hypertext Transfer Protocol  — application layer: the request or response

Vocabulary, before anything uses it#

The hard part: getting plain HTTP at all#

Nearly every site is HTTPS. HTTPS is HTTP inside TLS, and TLS is encrypted, so a capture of a normal browsing session shows rows labelled TLSv1.3 carrying Application Data — and no HTTP whatsoever. Wireshark is working correctly; there is genuinely no readable HTTP there to find.

Three ways to get a capture that really contains HTTP, in order of reliability:

• Use a site that still serves plain HTTP. Several sites are maintained specifically for protocol teaching and are reachable over http://. Type the http:// prefix explicitly, because browsers add https:// when you do not.
• Run a web server on your own machine and request http://localhost. Note that you must then capture on the loopback interface, not Wi-Fi, because the traffic never leaves the machine.
• Request a URL that is known to redirect. The initial plain-HTTP request and its 301 response are real HTTP, and they are enough to show a complete request and response pair.

And whichever you use, do a hard refresh. A browser that has the page cached will not send a request at all, and an empty capture after a page visibly loaded is nearly always this.

The capture, in six steps#

1. Close what you can. Chat clients, mail clients, streaming tabs — each one adds traffic you will have to filter out. A quiet machine makes a readable capture.
2. Pick the right interface. Wireshark’s opening screen lists interfaces with a live activity sparkline beside each. The one that is moving is the one carrying your traffic. Choose loopback only if you are requesting localhost.
3. Start the capture before you browse, not after. This is the step people get backwards.
4. Make the request. Go to the browser, type the http:// URL, and hard refresh.
5. Stop the capture as soon as the page has loaded. A capture left running for five minutes is a capture you will spend five minutes searching.
6. Apply the display filter http and press Enter.

Filters worth knowing, and the difference between the two kinds:

Reading the request#

Click a row whose Info column starts with GET. In the detail pane, expand Hypertext Transfer Protocol. You will see the request line first and then one row per header, in the order the browser sent them — which is exactly the message structure from the printed page, one line per row.

Wireshark adds three convenience rows that are not header fields, and knowing they are synthetic prevents confusion:

Answering the standard questions from the detail pane:

Reading the response#

With the http filter applied, the response is usually the next matching row, and Wireshark links them: the request detail contains [Response in frame: N], and the response contains [Request in frame: N]. Use those rather than guessing from timestamps.

Expand Hypertext Transfer Protocol on the response and the status line is the first row:

HTTP/1.1 200 OK\r\n
    [Status Code: 200]
    [Status Code Description: OK]
    Response Phrase: OK

Follow → HTTP Stream on either packet reassembles the whole conversation into plain text, request in one colour and response in another. It is the fastest way to see the two messages as messages rather than as tree rows, and it is worth doing once even when it is not what a question asks for.

Worked example#

Step 1 — Clear the filter and look at what is actually there. Do not adjust the filter yet. An empty result tells you nothing about what the capture contains; the unfiltered list tells you everything.

Step 2 — Read the Protocol column and match it to a cause. The column names the problem directly:

Step 3 — Fix the cause, not the filter. Each of those four has a different fix, and changing the filter fixes none of them.

TLS → use an http:// site  ·  cached → hard refresh

QUIC → use a plain-HTTP site  ·  empty → change interface

Step 4 — Recapture with the fix in place, then apply http again. Getting a clean capture is the skill; reading it afterwards takes a minute.

Practice#

Work these against a capture you took yourself. Answers to 4 to 9 will differ from anyone else’s, which is the point — what is being tested is whether you can find the field.

1. What is the difference between a capture filter and a display filter, and which is safer to experiment with?
2. Name the five protocol layers you expect in the detail pane of an HTTP packet, outermost first.
3. A filter of http returns nothing. Give four possible causes and the fix for each.
4. Take a capture of a plain-HTTP page. What method does your request use, and where in the message did you read it?
5. What host name did you visit, and which header carried it? Why is it not in the request line?
6. What is the connection status in your request, and what does that value mean for the TCP connection?
7. What is the status code and phrase of your response, and what class does the code belong to?
8. What HTTP version does your response use? Which field of which line is it in?
9. Does your response carry an Expires header? If not, what is there instead and what does it mean?
10. Expand the TCP layer of your request. Which port is the server and which is the client, and how do you know?

Solutions#

1. Applied while recording versus applied afterwards. A capture filter is applied while recording and permanently discards traffic that does not match. A display filter is applied to a capture you already have and only hides rows, so clearing it brings everything back. Display filters are safer to experiment with, and they use a different syntax — tcp.port == 80 rather than tcp port 80.
2. Frame, Ethernet, IP, TCP, HTTP. Frame (what the capture tool recorded), Ethernet II (link layer, MAC addresses), Internet Protocol (network layer, IP addresses), Transmission Control Protocol (transport layer, ports), and Hypertext Transfer Protocol (application layer, the message itself). Each wraps the one after it.
3. HTTPS, cache, QUIC, wrong interface. The site was HTTPS, so the traffic appears as TLS — use a plain-HTTP URL. The browser served the page from cache and sent no request — hard refresh. The connection used HTTP/3 over QUIC, which is UDP — use a site that speaks HTTP/1.1. Or the wrong interface was selected — pick the one showing activity, and use loopback only for localhost.
4. The first word of the request line. Almost certainly GET, read from the first field of the request line in the HTTP layer of the detail pane. If you submitted a form it may be POST.
5. The Host header. The Host header carried it. It is not in the request line because the request line contains only the path portion of the URL; HTTP/1.1 requires the separate Host header because one server with one IP address commonly serves many different websites.
6. The Connection header. Read the Connection header. keep-alive means the client is asking for the TCP connection to stay open for further requests; close means it should be torn down after this exchange. In HTTP/1.1 staying open is the default in any case.
7. The status line, first line of the response. Read the code and phrase from the status line — commonly 200 OK, and 301 Moved Permanently if you used a redirecting URL. The class is given by the first digit: 2xx success, 3xx redirection, 4xx client error, 5xx server error.
8. The first field of the status line. Usually HTTP/1.1. It is the first field of the status line, which is the reverse of the request, where the version comes last.
9. Expires, or Cache-Control max-age. Many modern responses have no Expires header and carry Cache-Control: max-age=N instead, which gives a lifetime in seconds from the time of the response rather than an absolute date. Saying that explicitly is a better answer than quoting Date or Last-Modified, neither of which is an expiry.
10. Port 80 is the server. The server is the end using port 80, the well-known port for HTTP. The other port is a high-numbered ephemeral port your operating system chose for this one connection. In the request the pair reads client to 80; in the response it reads 80 back to the client.

Test-readiness checklist#

• ☐  I can choose the right interface and say why loopback is different.
• ☐  I can start a capture, make one request, and stop it without collecting a minute of noise.
• ☐  I can write a display filter for requests only, responses only, and one host.
• ☐  I can say which kind of filter destroys data and which only hides it.
• ☐  I can name the five layers in the detail pane and say which wraps which.
• ☐  I can find the method, host, version and connection status in a request without hunting.
• ☐  I can find the status code, version, expiry and content length in a response without hunting.
• ☐  I can explain why a capture of an HTTPS site shows no HTTP.
• ☐  I can diagnose an empty http filter by looking at the Protocol column first.
• ☐  I can say which end of a TCP conversation is the server from the port numbers alone.

Frequently asked questions#

Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.