HTTP semantics across HTTP/1.1, HTTP/2, and HTTP/3

HTTP defines application-level request, response, method, status, representation, conditional, and intermediary semantics. HTTP/1.1, HTTP/2, and HTTP/3 share those semantics while using different message framing and transports.

Mental model

• The method expresses requested semantics. GET, HEAD, OPTIONS, and TRACE are safe; safe methods plus PUT and DELETE are idempotent by definition, while POST is not generally idempotent.
• Idempotent does not mean side-effect-free, identical response, or automatically safe under every application precondition.
• HTTP caching depends on cacheability, cache keys, freshness, validators, request directives, and the response chain—not on a universal TTL.
• HTTP/2 multiplexes streams over TCP. HTTP/3 maps HTTP over QUIC; stream independence reduces one transport loss coupling but does not eliminate all blocking.

Гарантии и границы

• A client cannot infer whether a mutation committed merely because its response was lost.
• A proxy must not automatically retry a non-idempotent request without knowledge that its semantics are idempotent.
• 304 validates a stored representation under conditional semantics and normally carries no representation content.
• 401 and 403, 502 and 504, and 429 each have defined semantics; operational causes still require telemetry.

Сценарии диаграммы

One HTTP request and final response. Methods and status codes carry semantics independently of the selected HTTP version.

Freshness and conditional validation. A stale stored response is not automatically reusable; validators can avoid retransmitting an unchanged representation.

Mutation retry after an ambiguous failure. HTTP method idempotency and application operation deduplication are related but not interchangeable.

Version-specific multiplexing and loss. HTTP semantics remain shared while framing and transport failure domains differ.

Архитектурные решения

• Design resources and methods first, then select the wire version based on client support, intermediary path, loss profile, and operations.
• Use application operation identities for retryable POST workflows; reject the same key with different intent.
• Make cache policy explicit with validators and Vary-aware keys; never label every 200 or POST response cacheable by default.

Сбои и неоднозначные исходы

• A transport close before a response is an ambiguous outcome for unsafe operations.
• HTTP/2 avoids application-level request serialization but inherits TCP connection-level loss ordering.
• HTTP/3 can fail where UDP is blocked and should have a measured fallback strategy.

Операционный checklist

• Specify method safety, idempotency, preconditions, status codes, and retry owner.
• Test cache freshness, validation, Vary, authorization, and invalidation.
• Measure per-version negotiation, fallback, stream limits, loss, and intermediary compatibility.
• Preserve Host or authority and trust only sanitized forwarding metadata.

Связанная концепция

Первичные источники

1. https://www.rfc-editor.org/rfc/rfc9110.html
2. https://www.rfc-editor.org/rfc/rfc9111.html
3. https://www.rfc-editor.org/rfc/rfc9112.html
4. https://www.rfc-editor.org/rfc/rfc9113.html
5. https://www.rfc-editor.org/rfc/rfc9114.html