HTTP 428 Precondition Required – Free, Online, Private

What HTTP 428 means

428 says the origin requires the request to be conditional, and this one was not. It is how a server prevents a lost update: a PUT without If-Match could overwrite a newer version, so the server refuses it. The client should GET, take the ETag, and retry with If-Match. RFC 6585 defines the status.

428 Precondition Required belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 428

When you see HTTP 428 Precondition Required, stop on that exact status line. 428 Precondition Required means the server will not accept the write without a precondition. The trace that usually produces it: PUT arrived without If-Match on a resource that requires it. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 428 when a state-changing method omits the precondition you require. Return 412 when the precondition was present and failed. Do not use 428 for a missing Content-Type or a missing auth header. It is specifically about conditional requests.

How to fix HTTP 428

To fix HTTP 428, change the condition that made the server choose Precondition Required. GET the resource and retry with the precondition. Do not invent an ETag. Do not retry the unconditional write. Yes, after you add a real precondition from a fresh GET. An identical retry fails. If the log line is a different code, leave this page. The mix-up people make with 428 is this one: 412 means a precondition was tested and failed. 428 means it was required and absent. 409 is a conflict you detected without this header dance.

• A client retried without adding the header and looped on 428.
• The server required If-Match on DELETE and the client only implemented it for PUT.
• A proxy stripped If-Match and the origin correctly answered 428.

An access log that only stores 428 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 428 Precondition RequiredHTTP/1.1 428 Precondition Required
Content-Type: application/json

{"error":"If-Match required"}

The body names the header. The client GETs the resource, reads ETag, and sends the write again with If-Match. If someone else writes in between, the retry gets 412 instead, which is the system working. Do not require a precondition you never document.

What the client should do

GET the resource and retry with the precondition. Do not invent an ETag. Do not retry the unconditional write.

Do not cache 428 as the resource. The GET you do next is the representation, and it carries the ETag.

Yes, after you add a real precondition from a fresh GET. An identical retry fails.

Codes people confuse with HTTP 428

412 means a precondition was tested and failed. 428 means it was required and absent. 409 is a conflict you detected without this header dance.