Httpbis Workgroup RFCs

Browse Httpbis Workgroup RFCs by Number

RFC6266 - Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP): RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]
RFC7230 - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing: The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.
RFC7231 - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content: The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.
RFC7232 - Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests: The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.
RFC7233 - Hypertext Transfer Protocol (HTTP/1.1): Range Requests: The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.
RFC7234 - Hypertext Transfer Protocol (HTTP/1.1): Caching: The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.
RFC7235 - Hypertext Transfer Protocol (HTTP/1.1): Authentication: The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.
RFC7236 - Initial Hypertext Transfer Protocol (HTTP) Authentication Scheme Registrations: This document registers Hypertext Transfer Protocol (HTTP) authentication schemes that have been defined in RFCs before the IANA HTTP Authentication Scheme Registry was established.
RFC7237 - Initial Hypertext Transfer Protocol (HTTP) Method Registrations: This document registers those Hypertext Transfer Protocol (HTTP) methods that have been defined in RFCs before the IANA HTTP Method Registry was established.
RFC7538 - The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect): This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).
RFC7540 - Hypertext Transfer Protocol Version 2 (HTTP/2): This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.; This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
RFC7541 - HPACK: Header Compression for HTTP/2: This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.
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."
RFC9110 - HTTP Semantics: The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.; This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.
RFC9111 - HTTP Caching: The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.; This document obsoletes RFC 7234.
RFC9112 - HTTP/1.1: The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns.; This document obsoletes portions of RFC 7230.
RFC9113 - HTTP/2: This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection.; This document obsoletes RFCs 7540 and 8740.
RFC9163 - Expect-CT Extension for HTTP: This document defines a new HTTP header field named "Expect-CT", which allows web host operators to instruct user agents (UAs) to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. Expect-CT allows web host operators to discover misconfigurations in their Certificate Transparency (CT) deployments. Further, web host operators can use Expect-CT to ensure that if a UA that supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs.
RFC9205 - Building Protocols with HTTP: Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations.; This document obsoletes RFC 3205.
RFC9209 - The Proxy-Status HTTP Response Header Field: This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors.
RFC9211 - The Cache-Status HTTP Response Header Field: To aid debugging, HTTP caches often append header fields to a response, explaining how they handled the request in an ad hoc manner. This specification defines a standard mechanism to do so that is aligned with HTTP's caching model.
RFC9213 - Targeted HTTP Cache Control: This specification defines a convention for HTTP response header fields that allow cache directives to be targeted at specific caches or classes of caches. It also defines one such header field, the CDN-Cache-Control response header field, which is targeted at content delivery network (CDN) caches.
RFC9218 - Extensible Prioritization Scheme for HTTP: This document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. This document defines the Priority header field for communicating the initial priority in an HTTP version-independent manner, as well as HTTP/2 and HTTP/3 frames for reprioritizing responses. These share a common format structure that is designed to provide future extensibility.
RFC9220 - Bootstrapping WebSockets with HTTP/3: The mechanism for running the WebSocket Protocol over a single stream of an HTTP/2 connection is equally applicable to HTTP/3, but the HTTP-version-specific details need to be specified. This document describes how the mechanism is adapted for HTTP/3.
RFC9292 - Binary Representation of HTTP Messages: This document defines a binary format for representing HTTP messages.
RFC9412 - The ORIGIN Extension in HTTP/3: The ORIGIN frame for HTTP/2 is equally applicable to HTTP/3, but it needs to be separately registered. This document describes the ORIGIN frame for HTTP/3.
RFC9421 - HTTP Message Signatures: This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.
RFC9440 - Client-Cert HTTP Header Field: This document describes HTTP extension header fields that allow a TLS terminating reverse proxy (TTRP) to convey the client certificate information of a mutually authenticated TLS connection to the origin server in a common and predictable manner.
RFC9530 - Digest Fields: This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields.; This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields.
RFC9532 - HTTP Proxy-Status Parameter for Next-Hop Aliases: This document defines the next-hop-aliases HTTP Proxy-Status Parameter. This parameter carries the list of aliases and canonical names an intermediary received during DNS resolution as part of establishing a connection to the next hop.