Summary

  • RFC 6265 describes the loop: a server sends Set-Cookie, the browser stores name/value pairs, and later applicable requests carry them back in Cookie. Its authors asked servers to keep cookies few and small because the request repeats them.
  • RFC 6585 introduced HTTP 431 in April 2012 for a request whose headers are too large together or in one field. The server may name the offending field; a reduced request may be tried again; caches must not store the 431 response.
  • HTTP/2 and HTTP/3 still allow a server to reject a field block or header section it will not handle. A compressed trip across the wire does not make the receiving service accept the contents.

A customer returns with the company's baggage

Picture a returning customer opening a website. The browser sends a request for the front page. Alongside the address, it carries a Cookie field assembled from state that the site previously asked it to retain: perhaps a session identifier, a preference and several experiments. The receiving service has a limit on the header section it will process. The request crosses that limit. The reply is 431. The customer has reached the same site that packed the baggage, yet the site declines to open it.

The two halves of this failure path appear in original Internet Engineering Task Force records. RFC 6265, published in April 2011, says a server uses Set-Cookie to put a name/value pair into a user agent. The agent decides when that pair applies, then sends it in Cookie on later requests. The attributes that govern scope and expiry stay in the browser; the name and value ride back. A single response can therefore add something small that returns again and again.

Section 6.1 of the cookie specification gives a striking asymmetry. It asks general-use browsers to support at least 4096 bytes for one cookie and at least 50 cookies per domain. It also asks servers to use as few and as small cookies as possible, explicitly because Cookie is included in every request. Those numbers measure browser storage. Each server, gateway and application separately decides how much of an incoming header it will read. One party's capacity to remember can outrun another party's willingness to read.

A new status code named the collision

In April 2012, RFC 6585 added four HTTP status codes. One of them, 431 Request Header Fields Too Large, gave the receiving service a precise way to refuse the oversized envelope. It applies if the whole collection of fields is too large or if one field is the offender. When a single field is at fault, the response should identify it. The specification even gives a sample page naming an Example header. It also says a request may be sent again after the fields are reduced.

That is a useful diagnosis, but it is thin medicine. The standard does not set one global byte ceiling. It does not tell a browser to remove a chosen cookie, tell a server which experiment to retire, or guarantee that the error page will be seen. RFC 6585 says a server under attack need not send 431 at all; dropping the connection may be more appropriate. A user who sees only a failed load cannot infer the rejecting component from the symptom. A proxy can reject a request before the origin's application code has a chance to respond.

The 431 response itself must not be stored by a cache. That rule keeps a temporary refusal from becoming a reusable answer for later requests with different headers. It does not shrink the next request. Each repeat visit can carry the same large field back to the same boundary. Clearing every cookie may change the request, but it may also end sessions and discard preferences. The record specifies a protocol response, not a safe automatic reset button.

A faster wire kept the same front door

The problem did not disappear when HTTP changed its transport. RFC 9113, the June 2022 HTTP/2 specification, says a server receiving a field block larger than it is willing to handle can send 431. RFC 9114 says the same for an HTTP/3 header section. Header compression can make repeated fields cheaper to transmit. The receiver still has to decide whether the resulting fields fit its processing budget.

This distinction matters in an incident room. A network graph may show a small compressed transfer while the application or an upstream gateway measures a larger decoded collection. The first engineer checks transport size; the second checks field size; the customer still gets an error. A useful diagnosis captures the actual request fields and the component that rejected them. It also distinguishes one giant field from the sum of many ordinary fields. The 431 code covers both cases.

Cookies are a natural suspect because the server can create them and the browser sends the applicable pairs back. They are not the only suspect. Authorization credentials and other request fields also consume the budget. The original RFCs supply no count of real 431 incidents caused by cookies, so the title names a possible causal loop rather than pretending a particular website confessed to one.

The operator owns the exit route

The revealing part of this history is who can repair the loop. The browser can stop sending some state. The customer can try a new session. But the operator chose what to set, how long it lives, what scope it covers, what a gateway accepts, and whether a recovery endpoint can be reached with a small request. If the only page that explains the failure requires carrying the same oversized header, the help desk is on the far side of the locked door.

RFC 6265 warned the issuer to keep state lean before 431 gave the recipient a named refusal. Taken together, the documents put an operating question behind a familiar web error: can the organization that created the header reduce it without making the customer discover the right cookie to delete? A 431 page can describe the obstruction. Only control of the state and the receiving limit can clear it.