Httpbis Workgroup RFCs

Browse Httpbis Workgroup RFCs by Number

RFC7615 - HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields
This specification defines the "Authentication-Info" and "Proxy- Authentication-Info" response header fields for use in Hypertext Transfer Protocol (HTTP) authentication schemes that need to return information once the client's authentication credentials have been accepted.
RFC7639 - The ALPN HTTP Header Field
This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.
RFC7694 - Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding
In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.
Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests.
RFC7725 - An HTTP Status Code to Report Legal Obstacles
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.
RFC7838 - HTTP Alternative Services
This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.
RFC8164 - Opportunistic Security for HTTP/2
This document describes how "http" URIs can be accessed using Transport Layer Security (TLS) and HTTP/2 to mitigate pervasive monitoring attacks. This mechanism not a replacement for "https" URIs; it is vulnerable to active attacks.
RFC8187 - Indicating Character Encoding and Language for HTTP Header Field Parameters
By default, header field values in Hypertext Transfer Protocol (HTTP) messages cannot easily carry characters outside the US-ASCII coded character set. RFC 2231 defines an encoding mechanism for use in parameters inside Multipurpose Internet Mail Extensions (MIME) header field values. This document specifies an encoding suitable for use in HTTP header fields that is compatible with a simplified profile of the encoding defined in RFC 2231.
This document obsoletes RFC 5987.
RFC8188 - Encrypted Content-Encoding for HTTP
This memo introduces a content coding for HTTP that allows message payloads to be encrypted.
RFC8246 - HTTP Immutable Responses
The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.
RFC8297 - An HTTP Status Code for Indicating Hints
This memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.
RFC8336 - The ORIGIN HTTP/2 Frame
This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.
RFC8441 - Bootstrapping WebSockets with HTTP/2
This document defines a mechanism for running the WebSocket Protocol (RFC 6455) over a single stream of an HTTP/2 connection.
RFC8470 - Using Early Data in HTTP
Using TLS early data creates an exposure to the possibility of a replay attack. This document defines mechanisms that allow clients to communicate with servers about HTTP requests that are sent in early data. Techniques are described that use these mechanisms to mitigate the risk of replay.
RFC8586 - Loop Detection in Content Delivery Networks (CDNs)
This document defines the CDN-Loop request header field for HTTP. CDN-Loop addresses an operational need that occurs when an HTTP request is intentionally forwarded between Content Delivery Networks (CDNs), but is then accidentally or maliciously re-routed back into the original CDN causing a non-terminating loop. The new header field can be used to identify the error and terminate the loop.
RFC8673 - HTTP Random Access and Live Content
To accommodate byte-range requests for content that has data appended over time, this document defines semantics that allow an HTTP client and a server to perform byte-range GET and HEAD requests that start at an arbitrary byte offset within the representation and end at an indeterminate offset.
RFC8740 - Using TLS 1.3 with HTTP/2
This document updates RFC 7540 by forbidding TLS 1.3 post-handshake authentication, as an analog to the existing TLS 1.2 renegotiation restriction.
RFC8941 - Structured Field Values for HTTP
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.
RFC8942 - HTTP Client Hints
HTTP defines proactive content negotiation to allow servers to select the appropriate response for a given request, based upon the user agent's characteristics, as expressed in request headers. In practice, user agents are often unwilling to send those request headers, because it is not clear whether they will be used, and sending them impacts both performance and privacy.
This document defines an Accept-CH response header that servers can use to advertise their use of request headers for proactive content negotiation, along with a set of guidelines for the creation of such headers, colloquially known as "Client Hints."