431: Reduce request headers
03A server rejects oversized request header fields; a smaller request can be submitted again.
A separate retry removes optional notes and passes this size check. Other request and authorization checks still apply.
Source for this drawing: RFC 6585 · Read RFC section 5 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Header field
- Named metadata sent with an HTTP request or response.
- Request content
- The request’s content bytes, separate from its header fields.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Distinguish header size from request content size.
- 431 Request Header Fields Too Large means the server is unwilling to process the request because its header fields are too large. It can refer to all fields together or one oversized field.
- The request MAY be resubmitted after reducing its header fields. If one field is at fault, the response representation SHOULD identify it. The RFC does not set a universal byte limit.
- 431 responses MUST NOT be stored by a cache. Servers under attack need not generate 431 and may instead drop connections or take other steps.
The drawing marks a fictional X-Notes field as too large and removes optional notes on a separate retry. It is not a measurement or a universal header-size threshold. Do not remove required authentication or security fields blindly. Request content that is too large has a different status, 413 (RFC 9110 §15.5.14).
Read the RFC section ↗