HTTP request and response analyzer

Paste a request, a response, or both one after the other. The analyzer accepts raw HTTP/1.1 as it appears on the wire or in a proxy log, and the output of curl -v, where sent lines start with > and received lines with <. Browser developer tools can show a request's raw headers in the network panel. Each header is explained with a link to the section of the RFC that defines it, 53 fields in all; the panel on the right lists problems, how long caches may keep the response, the conditional request a cache would send next, and checks on each cookie.

Everything runs in the page. Even so, remove passwords, tokens and session cookies before pasting real traffic; the address bar keeps what you paste so the link can be shared.

An HTTP request starts with a request line naming the method, the target (usually a path and query) and the protocol version, such as GET /news?page=2 HTTP/1.1. A response starts with a status line: the version, a three-digit status code and a reason phrase, such as HTTP/1.1 404 Not Found. Both continue with header fields, one Name: value per line, with names case-insensitive; an empty line ends the headers and the body, if any, follows.

Since 2022 the definitions are split: RFC 9110 gives the meaning of methods, status codes and fields for every version of HTTP, RFC 9112 the text format of HTTP/1.1, and RFC 9113 and RFC 9114 the binary framing of HTTP/2 and HTTP/3. The fields are the same in all of them (HTTP/2 and HTTP/3 move the request line into pseudo-headers such as :method and :path), so what this page says about headers applies to every version.

The first digit gives the class: 1xx informational, 2xx success, 3xx redirection, 4xx a problem with the request, 5xx a problem at the server. A few pairs are easy to confuse:

• 301 and 308 are permanent redirects; 302 and 307 temporary. With 301 and 302, browsers turn a POST into a GET when following; 307 and 308 require the same method and body.
• 303 See Other sends the client to another resource with GET, the usual answer to a form POST so that reloading the result does not resubmit it.
• 401 Unauthorized means "who are you?" and must carry WWW-Authenticate; 403 Forbidden means "I know, and no".
• 502 Bad Gateway and 504 Gateway Timeout come from a proxy or load balancer about the server behind it; 503 is the server saying it is overloaded or down for maintenance.

A cache may reuse a stored response without asking the server while it is fresh. RFC 9111 takes the freshness lifetime from s-maxage (shared caches only), then max-age, then Expires minus Date, and subtracts the response's age, which includes the Age header added by caches upstream. In the Static file example, max-age=31536000 gives 31,536,000 s and the response is already 3,600 s old, leaving 31,532,400 s. With none of these headers, a cache may use a heuristic for responses with Last-Modified; RFC 9111 mentions 10% of the time since the last change as typical, which gives the Only Last-Modified example 86,400 s.

When a stored response goes stale, the cache does not have to download it again. It sends a conditional request carrying the response's validators: If-None-Match with the ETag, or If-Modified-Since with Last-Modified. If nothing changed the server answers 304 Not Modified with headers only, and the cache keeps using its copy. no-cache forces this check on every use; no-store forbids keeping a copy at all; private keeps it out of shared caches such as CDNs.

A server sets a cookie with a Set-Cookie header, one per cookie, and the browser sends the stored cookies back in a single Cookie header. The attributes decide where and how long: Max-Age or Expires for lifetime (without them, the cookie lasts for the session), Domain and Path for scope, Secure for HTTPS only, HttpOnly to hide it from page scripts, and SameSite to control whether other sites' requests carry it. A session cookie should have all of Secure, HttpOnly and SameSite; in the Login and cookies example, __Host-session gets 0 warnings and theme gets 2 warnings. The __Host- name prefix makes the browser insist on Secure, Path=/ and no Domain, so a subdomain cannot overwrite the cookie.

Over HTTP/1.1 several messages share one connection, so each must say where its body ends: either Content-Length with the exact number of bytes, or Transfer-Encoding: chunked, which sends the body in pieces, each preceded by its size, and ends with a zero-size piece. A wrong Content-Length makes the receiver wait for bytes that never come, or read the start of the next message as part of this one. A message with both is suspicious: RFC 9112 says Transfer-Encoding wins and lets servers reject it, because a front-end proxy and a back-end server that disagree about the boundary can be made to see a hidden second request. The Common mistakes example has 7 problems, including that one.