freenode
Radar

HTTP WG moves to fence off status 402 as x402 spreads

Outside payment projects have assigned their own meaning to the long-reserved code; Mark Nottingham has floated a draft to limit collisions.

Martin Thomson has asked the IETF HTTP Working Group whether it should press external projects to stop redefining HTTP 402 Payment Required, after the Linux Foundation-backed x402 effort published its own semantics for the code.

RFC 9110 still lists 402 as reserved for future use. That has not stopped implementers. Thomson argued the IETF alone should define what status codes mean. Header fields that describe how to pay can live outside the IETF, he said, but the status code itself should not. He was blunt about the x402 materials, calling the work poor and likening it to AI slop, and equally blunt about the cryptocurrency focus of such schemes.

Mark Nottingham replied that x402 is only one of several attempts to put 402 to work, alongside h402, Lightning-linked L402/LSAT, an older HTTP payment authentication draft, and further expired proposals. Anders Rundgren added that x402-style payment flows already appear to be in production. The Linux Foundation has separately launched formal governance for x402 as an internet-native payments effort aimed at AI agents and applications, and Coinbase has claimed very large agent transaction counts on the scheme in coverage elsewhere.

Nottingham said he is not eager to spur micropayment work, given the well-known pitfalls, but that avoiding conflicts and bad practice may require the IETF to say something. He posted a short personal Internet-Draft toward that end and invited comment.

Tim Bray treated the idea of an enforcement crackdown as a joke and suggested the experiments might yet produce something the IETF can standardize. He favored Nottingham's draft in outline, while urging clearer text that a 402 response makes no legal claim and that implementers must weigh the legal setting of any payment activity. Rahul Gupta argued a useful 402 response should also tell the client how to prove payment on retry, for example with a token or receipt tied to the resource.