RFC 9110

Fielding, R. T., Nottingham, Mark, Reschke, & Julian. (2022). RFC 9110: HTTP Semantics.

Type

Report

Intellectual base

Grey literature

Year

2022

DOI

10.17487/rfc9110

DOI registrant

RFC Editor

Link

https://doi.org/10.17487/RFC9110

Cited by

6 citations across 6 artifacts.

Each citation links to the sentence it supports in the citing article.

Domain-specific

• Request-Response
  • HTTP instantiates the pattern in its canonical form: a client sends a method-plus-URI request with optional headers and body; a server returns a status code, headers, and optional body; the TCP connection or an explicit request identifier correlates them.

    This sourceThe current HTTP specification, defining the request as method-plus-target-URI with optional header fields and content, the response as status code plus header fields and content, and correlation as version-dependent - implicit message ordering on a connection, or an explicit identifier.

    SupportedVerified against the source

    Read by an automated reader; not a human review. How support was checked

• URL Redirection
  • RFC 9110 distinguishes permanent from temporary redirects and method-changing from method-preserving behavior; it also warns clients to intervene in cycles and to reconsider sensitive headers when the origin changes.

Mechanisms

• Absence Reason Enum
  • It is the same discipline HTTP encodes when it distinguishes `204 No Content` from `404 Not Found` from `403 Forbidden`.

    This sourceDefines distinct semantics for 204 No Content, 403 Forbidden, and 404 Not Found rather than collapsing those absence conditions.

• Backfill and Rebuild Job
  • It misleads when run carelessly: un-throttled, a rebuild can overwhelm the source it reads from; non-idempotent, a retried batch double-applies; and if it races the live change stream it can overwrite newer data with a stale re-derivation.
• Control API
  • - Publish the request→effect contract. Document exactly what each operation changes, its parameters, and its guarantees (including idempotency

    This sourceDocuments its guarantees (including idempotency).

• Maintenance Mode
  • So operations declares maintenance mode: the app returns an HTTP 503 "Service Unavailable"

    This sourceDefines HTTP 503 as Service Unavailable and permits Retry-After to indicate the expected period of unavailability.

Verification

Does it exist? Confirmed. This work's DOI resolves to a registered record, which fixes its identity. That is all it fixes.

Does it back the claim? Read against the text for 1 of 6 citations: 1 supported. Each verdict is shown under its citation below, with what in the work backs the sentence.

Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.

Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.

See how references were verified.

Links previously used in the corpus

Before the registry existed this work was also linked 2 other ways.

• https://www.rfc-editor.org/rfc/rfc9110.html ×2
• https://www.rfc-editor.org/rfc/rfc9110.html#section-15.4 ×1

Registry ID ref:e5a130fb89c6 · see in the full table