Structured Field Values for HTTP
RFC 8941
Document | Type | RFC - Proposed Standard (February 2021; No errata) | |
---|---|---|---|
Authors | Mark Nottingham , Poul-Henning Kamp | ||
Last updated | 2021-02-08 | ||
Replaces | draft-nottingham-structured-headers, draft-ietf-httpbis-jfv, draft-kamp-httpbis-structure | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication (wg milestone: - Submit Structured He... ) | |
Document shepherd | Tommy Pauly | ||
Shepherd write-up | Show (last changed 2020-04-08) | ||
IESG | IESG state | RFC 8941 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Barry Leiba | ||
Send notices to | Tommy Pauly <tpauly@apple.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | No IANA Actions |
Internet Engineering Task Force (IETF) M. Nottingham Request for Comments: 8941 Fastly Category: Standards Track P-H. Kamp ISSN: 2070-1721 The Varnish Cache Project February 2021 Structured Field Values for HTTP Abstract 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. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8941. Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 1.1. Intentionally Strict Processing 1.2. Notational Conventions 2. Defining New Structured Fields 3. Structured Data Types 3.1. Lists 3.1.1. Inner Lists 3.1.2. Parameters 3.2. Dictionaries 3.3. Items 3.3.1. Integers 3.3.2. Decimals 3.3.3. Strings 3.3.4. Tokens 3.3.5. Byte Sequences 3.3.6. Booleans 4. Working with Structured Fields in HTTP 4.1. Serializing Structured Fields 4.1.1. Serializing a List 4.1.2. Serializing a Dictionary 4.1.3. Serializing an Item 4.1.4. Serializing an Integer 4.1.5. Serializing a Decimal 4.1.6. Serializing a String 4.1.7. Serializing a Token 4.1.8. Serializing a Byte Sequence 4.1.9. Serializing a Boolean 4.2. Parsing Structured Fields 4.2.1. Parsing a List 4.2.2. Parsing a Dictionary 4.2.3. Parsing an Item 4.2.4. Parsing an Integer or Decimal 4.2.5. Parsing a String 4.2.6. Parsing a Token 4.2.7. Parsing a Byte Sequence 4.2.8. Parsing a Boolean 5. IANA Considerations 6. Security Considerations 7. References 7.1. Normative References 7.2. Informative References Appendix A. Frequently Asked Questions A.1. Why Not JSON? Appendix B. Implementation Notes Acknowledgements Authors' Addresses 1. Introduction Specifying the syntax of new HTTP header (and trailer) fields is an onerous task; even with the guidance in Section 8.3.1 of [RFC7231], there are many decisions -- and pitfalls -- for a prospective HTTP field author. Once a field is defined, bespoke parsers and serializers often need to be written, because each field value has a slightly different handling of what looks like common syntax. This document introduces a set of common data structures for use in definitions of new HTTP field values to address these problems. In particular, it defines a generic, abstract model for them, along with a concrete serialization for expressing that model in HTTP [RFC7230] header and trailer fields. An HTTP field that is defined as a "Structured Header" or "Structured Trailer" (if the field can be either, it is a "Structured Field") uses the types defined in this specification to define its syntax and basic handling rules, thereby simplifying both its definition by specification writers and handling by implementations. Additionally, future versions of HTTP can define alternative serializations of the abstract model of these structures, allowing fields that use that model to be transmitted more efficiently without being redefined. Note that it is not a goal of this document to redefine the syntax of existing HTTP fields; the mechanisms described herein are onlyShow full document text