HTTP (httpbis) Internet Drafts

 HTTP Client Hints
 Date: 03/07/2020
 Authors: Ilya Grigorik, Yoav Weiss
 Working Group: HTTP (httpbis)
 Formats: txt
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."
 Cookies: HTTP State Management Mechanism
 Date: 20/04/2020
 Authors: Mike West, John Wilander
 Working Group: HTTP (httpbis)
 Formats: txt xml
This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 6265.
 Structured Field Values for HTTP
 Date: 03/06/2020
 Authors: Mark Nottingham, Poul-Henning Kamp
 Working Group: HTTP (httpbis)
 Formats: xml txt
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.
 Expect-CT Extension for HTTP
 Date: 09/12/2018
 Working Group: HTTP (httpbis)
 Formats: xml txt
This document defines a new HTTP header field named Expect-CT, which allows web host operators to instruct user agents 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 deployments. Further, web host operaters can use Expect-CT to ensure that, if a UA which supports Expect-CT accepts a misissued certificate, that certificate will be discoverable in Certificate Transparency logs.
 Secondary Certificate Authentication in HTTP/2
 Date: 14/05/2020
 Authors: Mike Bishop, Nick Sullivan, Martin Thomson
 Working Group: HTTP (httpbis)
 Formats: txt xml
A use of TLS Exported Authenticators is described which enables HTTP/2 clients and servers to offer additional certificate-based credentials after the connection is established. The means by which these credentials are used with requests is defined.
 HTTP Caching
 Date: 27/08/2020
 Authors: Roy Fielding, Mark Nottingham, Julian Reschke
 Working Group: HTTP (httpbis)
 Formats: txt html xml
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.
 HTTP/1.1 Messaging
 Date: 27/08/2020
 Authors: Roy Fielding, Mark Nottingham, Julian Reschke
 Working Group: HTTP (httpbis)
 Formats: html xml txt
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.
 HTTP Semantics
 Date: 27/08/2020
 Authors: Roy Fielding, Mark Nottingham, Julian Reschke
 Working Group: HTTP (httpbis)
 Formats: txt html xml
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP: its architecture, terminology, the "http" and "https" Uniform Resource Identifier (URI) schemes, core request methods, request header fields, response status codes, response header fields, and content negotiation. This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC 7235, RFC 7538, RFC 7615, RFC 7694, and portions of RFC 7230.
 The Cache-Status HTTP Response Header Field
 Date: 11/08/2020
 Authors: Mark Nottingham
 Working Group: HTTP (httpbis)
 Formats: txt xml
To aid debugging, HTTP caches often append header fields to a response explaining how they handled the request. This specification codifies that practice and updates it to align with HTTP's current caching model.
 The Proxy-Status HTTP Response Header Field
 Date: 11/08/2020
 Authors: Mark Nottingham, Piotr Sikora
 Working Group: HTTP (httpbis)
 Formats: txt xml
This document defines the Proxy-Status HTTP field to convey the details of intermediary handling of responses, including generated errors.
 Digest Headers
 Date: 07/09/2020
 Authors: Roberto Polli, Lucas Pardue
 Working Group: HTTP (httpbis)
 Formats: xml txt
This document defines the HTTP Digest and Want-Digest fields, thus allowing client and server to negotiate an integrity checksum of the exchanged resource representation data. This document obsoletes RFC 3230. It replaces the term "instance" with "representation", which makes it consistent with the HTTP Semantic and Context defined in draft-ietf-httpbis-semantics.
 Extensible Prioritization Scheme for HTTP
 Date: 12/07/2020
 Authors: Kazuho Oku, Lucas Pardue
 Working Group: HTTP (httpbis)
 Formats: txt xml
This document describes a scheme for prioritizing HTTP responses. This scheme expresses the priority of each HTTP response using absolute values, rather than as a relative relationship between a group of HTTP responses. 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 the responses. These share a common format structure that is designed to provide future extensibility.
 Signing HTTP Messages
 Date: 10/04/2020
 Authors: Annabelle Backman, Justin Richer, Manu Sporny
 Working Group: HTTP (httpbis)
 Formats: html xml txt
This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over content within 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.

HTTP (httpbis)

Acronym httpbis
Area Applications and Real-Time Area (art)
State Active
Charter charter-ietf-httpbis-08 Approved
Dependencies Document dependency graph (SVG)
Additional Resources
- home page
- repositories
Personnel Chairs Mark Nottingham 
Tommy Pauly 
Area Director Barry Leiba 
Mailing list Address
To subscribe
Jabber chat Room address

Charter for Working Group

This Working Group is charged with maintaining and developing the "core" specifications for HTTP, and generic extensions to it (i.e., those that are not specific to one application).

Its current work items are:

# HTTP/1.1 Revision

After the revision of the core HTTP document set in the RFC723x series, the Working Group published HTTP/2, which defines an alternative mapping of HTTP's semantics to TCP, and introduced new capabilities, like Server Push.

Additionally, several ambiguities, interoperability issues and errata have been identified since their publication.

The Working Group will revise the "core" HTTP document set (RFC 7230-RFC 7235) to:

* Incorporate errata

* Address ambiguities

* Fix editorial problems which have led to misunderstandings of the specification

* Clarify conformance requirements

* Remove known ambiguities where they affect interoperability

* Clarify existing methods of extensibility

* Remove or deprecate those features that are not widely implemented and also unduly affect interoperability

* Where necessary, add implementation advice

In doing so, it should consider:

* Implementer experience

* Demonstrated use of HTTP

* Impact on existing implementations and deployments


Upon request from the QUIC Working Group, the HTTPBIS Working Group will review the QUIC Working Group's documents regarding the use of HTTP over the transport protocol they define, providing feedback and collaborating where necessary.

Once the QUIC Working Group publishes the expression of HTTP semantics in QUIC (HTTP/3), the HTTPBIS Working Group will maintain and develop extensions for HTTP/3 as necessary. This includes ancillary specifications (e.g. QPACK).

# Other HTTP-Related Work

The Working Group may define extensions and other documents related to HTTP as work items, provided that:

* They are generic; i.e., not specific to one application using HTTP. Note that Web browsing by definition is a generic use.

* The Working Group Chairs judge that there is consensus to take on the item and believe that it will not interfere with the work described above, and

* The Area Director approves the addition and add corresponding milestones.


Order Milestone
Last Submit Digest Headers
Submit Proxy-Status Header
Submit Cache-Status Header
Submit HTTP Representation Variants
Submit Building Protocols with HTTP (BCP56bis)
Submit Secondary Certificates
Submit Structured Headers
Submit Client Hints
Submit RFC6265bis (Cookies)
Next Submit the "core" HTTP documents for consideration as Internet Standards