draft-ietf-httpbis-header-structure-10.txt   draft-ietf-httpbis-header-structure-latest.txt 
HTTP Working Group M. Nottingham HTTP Working Group M. Nottingham
Internet-Draft Fastly Internet-Draft Fastly
Intended status: Standards Track P-H. Kamp Intended status: Standards Track P-H. Kamp
Expires: October 19, 2019 The Varnish Cache Project Expires: October 26, 2019 The Varnish Cache Project
April 17, 2019 April 24, 2019
Structured Headers for HTTP Structured Headers for HTTP
draft-ietf-httpbis-header-structure-10 draft-ietf-httpbis-header-structure-latest
Abstract Abstract
This document describes a set of data types and algorithms associated This document describes a set of data types and algorithms associated
with them that are intended to make it easier and safer to define and with them that are intended to make it easier and safer to define and
handle HTTP header fields. It is intended for use by new handle HTTP header fields. It is intended for use by new
specifications of HTTP header fields as well as revisions of existing specifications of HTTP header fields as well as revisions of existing
header field specifications when doing so does not cause header field specifications when doing so does not cause
interoperability issues. interoperability issues.
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 19, 2019. This Internet-Draft will expire on October 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 48 skipping to change at page 2, line 48
3.5. Items . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Items . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Integers . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Integers . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7. Floats . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Floats . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.8. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.9. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.9. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.10. Byte Sequences . . . . . . . . . . . . . . . . . . . . . 11 3.10. Byte Sequences . . . . . . . . . . . . . . . . . . . . . 11
3.11. Booleans . . . . . . . . . . . . . . . . . . . . . . . . 11 3.11. Booleans . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Structured Headers in HTTP/1 . . . . . . . . . . . . . . . . 12 4. Structured Headers in HTTP/1 . . . . . . . . . . . . . . . . 12
4.1. Serialising Structured Headers into HTTP/1 . . . . . . . 12 4.1. Serialising Structured Headers into HTTP/1 . . . . . . . 12
4.2. Parsing HTTP/1 Header Fields into Structured Headers . . 18 4.2. Parsing HTTP/1 Header Fields into Structured Headers . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . 29
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 30
Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 30 Appendix B. Frequently Asked Questions . . . . . . . . . . . . . 30
B.1. Why not JSON? . . . . . . . . . . . . . . . . . . . . . . 30 B.1. Why not JSON? . . . . . . . . . . . . . . . . . . . . . . 30
B.2. Structured Headers don't "fit" my data. . . . . . . . . . 30 B.2. Structured Headers don't "fit" my data. . . . . . . . . . 31
B.3. What should generic Structured Headers implementations B.3. What should generic Structured Headers implementations
expose? . . . . . . . . . . . . . . . . . . . . . . . . . 31 expose? . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 31 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 31
C.1. Since draft-ietf-httpbis-header-structure-09 . . . . . . 31 C.1. Since draft-ietf-httpbis-header-structure-10 . . . . . . 32
C.2. Since draft-ietf-httpbis-header-structure-08 . . . . . . 32 C.2. Since draft-ietf-httpbis-header-structure-09 . . . . . . 32
C.3. Since draft-ietf-httpbis-header-structure-07 . . . . . . 32 C.3. Since draft-ietf-httpbis-header-structure-08 . . . . . . 32
C.4. Since draft-ietf-httpbis-header-structure-06 . . . . . . 33 C.4. Since draft-ietf-httpbis-header-structure-07 . . . . . . 32
C.5. Since draft-ietf-httpbis-header-structure-05 . . . . . . 33 C.5. Since draft-ietf-httpbis-header-structure-06 . . . . . . 33
C.6. Since draft-ietf-httpbis-header-structure-04 . . . . . . 33 C.6. Since draft-ietf-httpbis-header-structure-05 . . . . . . 33
C.7. Since draft-ietf-httpbis-header-structure-03 . . . . . . 33 C.7. Since draft-ietf-httpbis-header-structure-04 . . . . . . 33
C.8. Since draft-ietf-httpbis-header-structure-02 . . . . . . 33 C.8. Since draft-ietf-httpbis-header-structure-03 . . . . . . 33
C.9. Since draft-ietf-httpbis-header-structure-01 . . . . . . 34 C.9. Since draft-ietf-httpbis-header-structure-02 . . . . . . 33
C.10. Since draft-ietf-httpbis-header-structure-00 . . . . . . 34 C.10. Since draft-ietf-httpbis-header-structure-01 . . . . . . 34
C.11. Since draft-ietf-httpbis-header-structure-00 . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Specifying the syntax of new HTTP header fields is an onerous task; Specifying the syntax of new HTTP header fields is an onerous task;
even with the guidance in [RFC7231], Section 8.3.1, there are many even with the guidance in [RFC7231], Section 8.3.1, there are many
decisions - and pitfalls - for a prospective HTTP header field decisions - and pitfalls - for a prospective HTTP header field
author. author.
Once a header field is defined, bespoke parsers and serialisers often Once a header field is defined, bespoke parsers and serialisers often
skipping to change at page 11, line 18 skipping to change at page 11, line 18
Parsers MUST support strings with at least 1024 characters. Parsers MUST support strings with at least 1024 characters.
3.9. Tokens 3.9. Tokens
Tokens are short textual words; their abstract model is identical to Tokens are short textual words; their abstract model is identical to
their expression in the textual HTTP serialisation. their expression in the textual HTTP serialisation.
The ABNF for tokens in HTTP/1 headers is: The ABNF for tokens in HTTP/1 headers is:
sh-token = ALPHA *( ALPHA / DIGIT / "_" / "-" / "." / ":" / "%" / "*" / "/" ) sh-token = ALPHA
*( ALPHA / DIGIT / "_" / "-" / "." / ":" / "%"
/ "*" / "/" )
Parsers MUST support tokens with at least 512 characters. Parsers MUST support tokens with at least 512 characters.
Note that a Structured Header token is not the same as the "token" Note that a Structured Header token is not the same as the "token"
ABNF rule defined in [RFC7230]. ABNF rule defined in [RFC7230].
3.10. Byte Sequences 3.10. Byte Sequences
Byte sequences can be conveyed in Structured Headers. Byte sequences can be conveyed in Structured Headers.
skipping to change at page 28, line 10 skipping to change at page 28, line 22
5. IANA Considerations 5. IANA Considerations
This draft has no actions for IANA. This draft has no actions for IANA.
6. Security Considerations 6. Security Considerations
The size of most types defined by Structured Headers is not limited; The size of most types defined by Structured Headers is not limited;
as a result, extremely large header fields could be an attack vector as a result, extremely large header fields could be an attack vector
(e.g., for resource consumption). Most HTTP implementations limit (e.g., for resource consumption). Most HTTP implementations limit
the sizes of size of individual header fields as well as the overall the sizes of individual header fields as well as the overall header
header block size to mitigate such attacks. block size to mitigate such attacks.
It is possible for parties with the ability to inject new HTTP header It is possible for parties with the ability to inject new HTTP header
fields to change the meaning of a Structured Header. In some fields to change the meaning of a Structured Header. In some
circumstances, this will cause parsing to fail, but it is not circumstances, this will cause parsing to fail, but it is not
possible to reliably fail in all such circumstances. possible to reliably fail in all such circumstances.
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 31, line 47 skipping to change at page 32, line 5
Implementers should note that dictionaries and parameters are order- Implementers should note that dictionaries and parameters are order-
preserving maps. Some headers may not convey meaning in the ordering preserving maps. Some headers may not convey meaning in the ordering
of these data types, but it should still be exposed so that of these data types, but it should still be exposed so that
applications which need to use it will have it available. applications which need to use it will have it available.
Appendix C. Changes Appendix C. Changes
_RFC Editor: Please remove this section before publication._ _RFC Editor: Please remove this section before publication._
C.1. Since draft-ietf-httpbis-header-structure-09 C.1. Since draft-ietf-httpbis-header-structure-10
_None yet._
C.2. Since draft-ietf-httpbis-header-structure-09
o Changed Boolean from T/F to 1/0 (#784). o Changed Boolean from T/F to 1/0 (#784).
o Parameters are now ordered maps (#765). o Parameters are now ordered maps (#765).
o Clamp integers to 15 digits (#737). o Clamp integers to 15 digits (#737).
C.2. Since draft-ietf-httpbis-header-structure-08 C.3. Since draft-ietf-httpbis-header-structure-08
o Disallow whitespace before items properly (#703). o Disallow whitespace before items properly (#703).
o Created "key" for use in dictionaries and parameters, rather than o Created "key" for use in dictionaries and parameters, rather than
relying on identifier (#702). Identifiers have a separate minimum relying on identifier (#702). Identifiers have a separate minimum
supported size. supported size.
o Expanded the range of special characters allowed in identifier to o Expanded the range of special characters allowed in identifier to
include all of ALPHA, ".", ":", and "%" (#702). include all of ALPHA, ".", ":", and "%" (#702).
skipping to change at page 32, line 31 skipping to change at page 32, line 41
o Gave better names for referring specs to use in Parameterised o Gave better names for referring specs to use in Parameterised
Lists (#720). Lists (#720).
o Added Lists of Lists (#721). o Added Lists of Lists (#721).
o Rename Identifier to Token (#725). o Rename Identifier to Token (#725).
o Add implementation guidance (#727). o Add implementation guidance (#727).
C.3. Since draft-ietf-httpbis-header-structure-07 C.4. Since draft-ietf-httpbis-header-structure-07
o Make Dictionaries ordered mappings (#659). o Make Dictionaries ordered mappings (#659).
o Changed "binary content" to "byte sequence" to align with Infra o Changed "binary content" to "byte sequence" to align with Infra
specification (#671). specification (#671).
o Changed "mapping" to "map" for #671. o Changed "mapping" to "map" for #671.
o Don't fail if byte sequences aren't "=" padded (#658). o Don't fail if byte sequences aren't "=" padded (#658).
o Add Booleans (#683). o Add Booleans (#683).
o Allow identifiers in items again (#629). o Allow identifiers in items again (#629).
o Disallowed whitespace before items (#703). o Disallowed whitespace before items (#703).
o Explain the consequences of splitting a string across multiple o Explain the consequences of splitting a string across multiple
headers (#686). headers (#686).
C.4. Since draft-ietf-httpbis-header-structure-06 C.5. Since draft-ietf-httpbis-header-structure-06
o Add a FAQ. o Add a FAQ.
o Allow non-zero pad bits. o Allow non-zero pad bits.
o Explicitly check for integers that violate constraints. o Explicitly check for integers that violate constraints.
C.5. Since draft-ietf-httpbis-header-structure-05 C.6. Since draft-ietf-httpbis-header-structure-05
o Reorganise specification to separate parsing out. o Reorganise specification to separate parsing out.
o Allow referencing specs to use ABNF. o Allow referencing specs to use ABNF.
o Define serialisation algorithms. o Define serialisation algorithms.
o Refine relationship between ABNF, parsing and serialisation o Refine relationship between ABNF, parsing and serialisation
algorithms. algorithms.
C.6. Since draft-ietf-httpbis-header-structure-04 C.7. Since draft-ietf-httpbis-header-structure-04
o Remove identifiers from item. o Remove identifiers from item.
o Remove most limits on sizes. o Remove most limits on sizes.
o Refine number parsing. o Refine number parsing.
C.7. Since draft-ietf-httpbis-header-structure-03 C.8. Since draft-ietf-httpbis-header-structure-03
o Strengthen language around failure handling. o Strengthen language around failure handling.
C.8. Since draft-ietf-httpbis-header-structure-02 C.9. Since draft-ietf-httpbis-header-structure-02
o Split Numbers into Integers and Floats. o Split Numbers into Integers and Floats.
o Define number parsing. o Define number parsing.
o Tighten up binary parsing and give it an explicit end delimiter. o Tighten up binary parsing and give it an explicit end delimiter.
o Clarify that mappings are unordered. o Clarify that mappings are unordered.
o Allow zero-length strings. o Allow zero-length strings.
o Improve string parsing algorithm. o Improve string parsing algorithm.
o Improve limits in algorithms. o Improve limits in algorithms.
o Require parsers to combine header fields before processing. o Require parsers to combine header fields before processing.
o Throw an error on trailing garbage. o Throw an error on trailing garbage.
C.9. Since draft-ietf-httpbis-header-structure-01 C.10. Since draft-ietf-httpbis-header-structure-01
o Replaced with draft-nottingham-structured-headers. o Replaced with draft-nottingham-structured-headers.
C.10. Since draft-ietf-httpbis-header-structure-00 C.11. Since draft-ietf-httpbis-header-structure-00
o Added signed 64bit integer type. o Added signed 64bit integer type.
o Drop UTF8, and settle on BCP137 ::EmbeddedUnicodeChar for h1- o Drop UTF8, and settle on BCP137 ::EmbeddedUnicodeChar for h1-
unicode-string. unicode-string.
o Change h1_blob delimiter to ":" since "'" is valid t_char o Change h1_blob delimiter to ":" since "'" is valid t_char
Authors' Addresses Authors' Addresses
 End of changes. 18 change blocks. 
29 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/