draft-ietf-httpbis-header-structure-07.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: January 3, 2019 The Varnish Cache Project Expires: February 11, 2019 The Varnish Cache Project
July 2, 2018 August 10, 2018
Structured Headers for HTTP Structured Headers for HTTP
draft-ietf-httpbis-header-structure-07 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 January 3, 2019. This Internet-Draft will expire on February 11, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 44 skipping to change at page 2, line 44
3.2. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Parameterised Lists . . . . . . . . . . . . . . . . . . . 7 3.3. Parameterised Lists . . . . . . . . . . . . . . . . . . . 7
3.4. Items . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Items . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5. Integers . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Integers . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Floats . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Floats . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Strings . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.8. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 9 3.8. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 9
3.9. Binary Content . . . . . . . . . . . . . . . . . . . . . 9 3.9. Binary Content . . . . . . . . . . . . . . . . . . . . . 9
4. Structured Headers in HTTP/1 . . . . . . . . . . . . . . . . 10 4. Structured Headers in HTTP/1 . . . . . . . . . . . . . . . . 10
4.1. Serialising Structured Headers into HTTP/1 . . . . . . . 10 4.1. Serialising Structured Headers into HTTP/1 . . . . . . . 10
4.2. Parsing HTTP/1 Header Fields into Structured Headers . . 14 4.2. Parsing HTTP/1 Header Fields into Structured Headers . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.1. Normative References . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . 23
7.2. Informative References . . . . . . . . . . . . . . . . . 23 7.2. Informative References . . . . . . . . . . . . . . . . . 23
7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 24 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 24
A.1. Why not JSON? . . . . . . . . . . . . . . . . . . . . . . 24 A.1. Why not JSON? . . . . . . . . . . . . . . . . . . . . . . 24
A.2. Structured Headers don't "fit" my data. . . . . . . . . . 25 A.2. Structured Headers don't "fit" my data. . . . . . . . . . 25
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 25
B.1. Since draft-ietf-httpbis-header-structure-06 . . . . . . 25 B.1. Since draft-ietf-httpbis-header-structure-06 . . . . . . 26
B.2. Since draft-ietf-httpbis-header-structure-05 . . . . . . 25 B.2. Since draft-ietf-httpbis-header-structure-05 . . . . . . 26
B.3. Since draft-ietf-httpbis-header-structure-04 . . . . . . 26 B.3. Since draft-ietf-httpbis-header-structure-04 . . . . . . 26
B.4. Since draft-ietf-httpbis-header-structure-03 . . . . . . 26 B.4. Since draft-ietf-httpbis-header-structure-03 . . . . . . 26
B.5. Since draft-ietf-httpbis-header-structure-02 . . . . . . 26 B.5. Since draft-ietf-httpbis-header-structure-02 . . . . . . 26
B.6. Since draft-ietf-httpbis-header-structure-01 . . . . . . 26 B.6. Since draft-ietf-httpbis-header-structure-01 . . . . . . 27
B.7. Since draft-ietf-httpbis-header-structure-00 . . . . . . 26 B.7. Since draft-ietf-httpbis-header-structure-00 . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 4, line 18 skipping to change at page 4, line 18
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the Augmented Backus-Naur Form (ABNF) notation of This document uses the Augmented Backus-Naur Form (ABNF) notation of
[RFC5234], including the VCHAR, DIGIT, ALPHA and DQUOTE rules from [RFC5234], including the VCHAR, SP, DIGIT, ALPHA and DQUOTE rules
that document. It also includes the OWS rule from [RFC7230]. from that document. It also includes the OWS rule from [RFC7230].
This document uses algorithms to specify parsing and serialisation This document uses algorithms to specify parsing and serialisation
behaviours, and ABNF to illustrate expected syntax. behaviours, and ABNF to illustrate expected syntax.
For parsing, implementations MUST follow the algorithms, but MAY vary For parsing, implementations MUST follow the algorithms, but MAY vary
in implementation so as the behaviours are indistinguishable from in implementation so as the behaviours are indistinguishable from
specified behaviour. If there is disagreement between the parsing specified behaviour. If there is disagreement between the parsing
algorithms and ABNF, the specified algorithms take precedence. algorithms and ABNF, the specified algorithms take precedence.
For serialisation, the ABNF illustrates the range of acceptable wire For serialisation, the ABNF illustrates the range of acceptable wire
skipping to change at page 5, line 8 skipping to change at page 5, line 8
semantics. Syntax definitions are encouraged to use the ABNF semantics. Syntax definitions are encouraged to use the ABNF
rules beginning with "sh-" defined in this specification. rules beginning with "sh-" defined in this specification.
o Specify any additional constraints upon the syntax of the o Specify any additional constraints upon the syntax of the
structured used, as well as the consequences when those structured used, as well as the consequences when those
constraints are violated. When Structured Headers parsing fails, constraints are violated. When Structured Headers parsing fails,
the header is discarded (see Section 4.2); in most situations, the header is discarded (see Section 4.2); in most situations,
header-specific constraints should do likewise. header-specific constraints should do likewise.
Note that a header field definition cannot relax the requirements of Note that a header field definition cannot relax the requirements of
a structure or its processing; they can only add additional a structure or its processing because doing so would preclude
constraints, because doing so would preclude handling by generic handling by generic software; they can only add additional
software. constraints.
For example: For example:
# Foo-Example Header # Foo-Example Header
The Foo-Example HTTP header field conveys information about how The Foo-Example HTTP header field conveys information about how
much Foo the message has. much Foo the message has.
Foo-Example is a Structured Header [RFCxxxx]. Its value MUST be a Foo-Example is a Structured Header [RFCxxxx]. Its value MUST be a
dictionary ([RFCxxxx], Section Y.Y). Its ABNF is: dictionary ([RFCxxxx], Section Y.Y). Its ABNF is:
skipping to change at page 6, line 35 skipping to change at page 6, line 35
sh-dictionary = dict-member *( OWS "," OWS dict-member ) sh-dictionary = dict-member *( OWS "," OWS dict-member )
dict-member = member-name "=" member-value dict-member = member-name "=" member-value
member-name = identifier member-name = identifier
member-value = sh-item member-value = sh-item
In HTTP/1, keys and values are separated by "=" (without whitespace), In HTTP/1, keys and values are separated by "=" (without whitespace),
and key/value pairs are separated by a comma with optional and key/value pairs are separated by a comma with optional
whitespace. For example: whitespace. For example:
Example-DictHeader: en="Applepie", da=*w4ZibGV0w6ZydGUK=* Example-DictHeader: en="Applepie", da=*w4ZibGV0w6ZydGU=*
Typically, a header field specification will define the semantics of Typically, a header field specification will define the semantics of
individual keys, as well as whether their presence is required or individual keys, as well as whether their presence is required or
optional. Recipients MUST ignore keys that are undefined or unknown, optional. Recipients MUST ignore keys that are undefined or unknown,
unless the header field's specification specifically disallows them. unless the header field's specification specifically disallows them.
Parsers MUST support dictionaries containing at least 1024 key/value Parsers MUST support dictionaries containing at least 1024 key/value
pairs. pairs.
3.2. Lists 3.2. Lists
skipping to change at page 7, line 20 skipping to change at page 7, line 20
Header specifications can constrain the types of individual values if Header specifications can constrain the types of individual values if
necessary. necessary.
Parsers MUST support lists containing at least 1024 members. Parsers MUST support lists containing at least 1024 members.
3.3. Parameterised Lists 3.3. Parameterised Lists
Parameterised Lists are arrays of a parameterised identifiers. Parameterised Lists are arrays of a parameterised identifiers.
A parameterised identifier is an identifier (Section 3.8) with an A parameterised identifier is an identifier (Section 3.8) with an
optional set of parameters, each parameter having a identifier and an optional set of parameters, each parameter having an identifier and
optional value that is an item (Section 3.4). Ordering between an optional value that is an item (Section 3.4). Ordering between
parameters is not significant, and duplicate parameters MUST cause parameters is not significant, and duplicate parameters MUST cause
parsing to fail. parsing to fail.
The ABNF for parameterised lists is: The ABNF for parameterised lists is:
sh-param-list = param-id *( OWS "," OWS param-id ) sh-param-list = param-id *( OWS "," OWS param-id )
param-id = identifier *parameter param-id = identifier *parameter
parameter = OWS ";" OWS param-name [ "=" param-value ] parameter = OWS ";" OWS param-name [ "=" param-value ]
param-name = identifier param-name = identifier
param-value = sh-item param-value = sh-item
In HTTP/1, each param-id is separated by a comma and optional In HTTP/1, each param-id is separated by a comma and optional
whitespace (as in Lists), and the parameters are separated by whitespace (as in Lists), and the parameters are separated by
semicolons. For example: semicolons. For example:
Example-ParamListHeader: abc_123;a=1;b=2; cdef_456, ghi;q="9";r=w Example-ParamListHeader: abc_123;a=1;b=2; cdef_456, ghi;q="9";r="w"
Parsers MUST support parameterised lists containing at least 1024 Parsers MUST support parameterised lists containing at least 1024
members, and support members with at least 256 parameters. members, and support members with at least 256 parameters.
3.4. Items 3.4. Items
An item is can be a integer (Section 3.5), float (Section 3.6), An item is can be a integer (Section 3.5), float (Section 3.6),
string (Section 3.7), or binary content (Section 3.9). string (Section 3.7), or binary content (Section 3.9).
The ABNF for items is: The ABNF for items is:
skipping to change at page 9, line 26 skipping to change at page 9, line 26
Note that strings only use DQUOTE as a delimiter; single quotes do Note that strings only use DQUOTE as a delimiter; single quotes do
not delimit strings. Furthermore, only DQUOTE and "\" can be not delimit strings. Furthermore, only DQUOTE and "\" can be
escaped; other sequences MUST cause parsing to fail. escaped; other sequences MUST cause parsing to fail.
Unicode is not directly supported in this document, because it causes Unicode is not directly supported in this document, because it causes
a number of interoperability issues, and - with few exceptions - a number of interoperability issues, and - with few exceptions -
header values do not require it. header values do not require it.
When it is necessary for a field value to convey non-ASCII string When it is necessary for a field value to convey non-ASCII string
content, binary content (Section 3.9) SHOULD be specified, along with content, binary content (Section 3.9) SHOULD be specified, along with
a character encoding (preferably, UTF-8). a character encoding (preferably UTF-8).
Parsers MUST support strings with at least 1024 characters. Parsers MUST support strings with at least 1024 characters.
3.8. Identifiers 3.8. Identifiers
Identifiers are short textual identifiers; their abstract model is Identifiers are short textual identifiers; their abstract model is
identical to their expression in the textual HTTP serialisation. identical to their expression in the textual HTTP serialisation.
Parsers MUST support identifiers with at least 64 characters. Parsers MUST support identifiers with at least 64 characters.
The ABNF for identifiers is: The ABNF for identifiers is:
skipping to change at page 11, line 10 skipping to change at page 11, line 10
2. Append name to output. 2. Append name to output.
3. Append "=" to output. 3. Append "=" to output.
4. Let value be the result of applying Serialising an Item 4. Let value be the result of applying Serialising an Item
Section 4.1.4 to mem's member-value. Section 4.1.4 to mem's member-value.
5. Append value to output. 5. Append value to output.
6. If more members remain in input:
1. Append a COMMA to output.
2. Append a single WS to output.
3. Return output. 3. Return output.
4.1.2. Serialising a List 4.1.2. Serialising a List
Given a list as input: Given a list as input:
1. Let output be an empty string. 1. Let output be an empty string.
2. For each member mem of input: 2. For each member mem of input:
skipping to change at page 11, line 48 skipping to change at page 12, line 5
2. For each member mem of input: 2. For each member mem of input:
1. Let id be the result of applying Serialising an Identifier 1. Let id be the result of applying Serialising an Identifier
Section 4.1.8 to mem's identifier. Section 4.1.8 to mem's identifier.
2. Append id to output. 2. Append id to output.
3. For each parameter in mem's parameters: 3. For each parameter in mem's parameters:
1. Let name be the result of applying Serialising an 1. Append ";" to output.
2. Let name be the result of applying Serialising an
Identifier Section 4.1.8 to parameter's param-name. Identifier Section 4.1.8 to parameter's param-name.
2. Append name to output. 3. Append name to output.
3. If parameter has a param-value: 4. If parameter has a param-value:
1. Let value be the result of applying Serialising an 1. Let value be the result of applying Serialising an
Item Section 4.1.4 to parameter's param-value. Item Section 4.1.4 to parameter's param-value.
2. Append "=" to output. 2. Append "=" to output.
3. Append value to output. 3. Append value to output.
4. If more members remain in input:
1. Append a COMMA to output.
2. Append a single WS to output.
3. Return output. 3. Return output.
4.1.4. Serialising an Item 4.1.4. Serialising an Item
Given an item as input: Given an item as input:
1. If input is a type other than an integer, float, string or binary 1. If input is a type other than an integer, float, string or binary
content, fail serialisation. content, fail serialisation.
2. Let output be an empty string. 2. Let output be an empty string.
skipping to change at page 13, line 33 skipping to change at page 13, line 48
6. Append input's decimal component represented in base 10 using 6. Append input's decimal component represented in base 10 using
only decimal digits to output; if it is zero, append "0". only decimal digits to output; if it is zero, append "0".
7. Return output. 7. Return output.
4.1.7. Serialising a String 4.1.7. Serialising a String
Given a string as input: Given a string as input:
1. If input is not a sequence of characters, or contains characters 1. If input is not a sequence of characters, or contains characters
outside the range allowed by VCHAR, fail serialisation. outside the range allowed by VCHAR or SP, fail serialisation.
2. Let output be an empty string. 2. Let output be an empty string.
3. Append DQUOTE to output. 3. Append DQUOTE to output.
4. For each character char in input: 4. For each character char in input:
1. If char is "\" or DQUOTE: 1. If char is "\" or DQUOTE:
1. Append "\" to output. 1. Append "\" to output.
skipping to change at page 17, line 43 skipping to change at page 18, line 7
COMMA, fail parsing. COMMA, fail parsing.
6. Discard any leading OWS from input_string. 6. Discard any leading OWS from input_string.
7. If input_string is empty, fail parsing. 7. If input_string is empty, fail parsing.
3. No structured data has been found; fail parsing. 3. No structured data has been found; fail parsing.
4.2.4. Parsing a Parameterised Identifier from Text 4.2.4. Parsing a Parameterised Identifier from Text
Given an ASCII string input_string, return a identifier with an Given an ASCII string input_string, return an identifier with a
mapping of parameters. input_string is modified to remove the parsed mapping of parameters. input_string is modified to remove the parsed
value. value.
1. Let primary_identifier be the result of Parsing a Identifier from 1. Let primary_identifier be the result of Parsing an Identifier
Text (Section 4.2.8) from input_string. from Text (Section 4.2.8) from input_string.
2. Let parameters be an empty, unordered mapping. 2. Let parameters be an empty, unordered mapping.
3. In a loop: 3. In a loop:
1. Discard any leading OWS from input_string. 1. Discard any leading OWS from input_string.
2. If the first character of input_string is not ";", exit the 2. If the first character of input_string is not ";", exit the
loop. loop.
3. Consume a ";" character from the beginning of input_string. 3. Consume a ";" character from the beginning of input_string.
4. Discard any leading OWS from input_string. 4. Discard any leading OWS from input_string.
5. let param_name be the result of Parsing a Identifier from 5. let param_name be the result of Parsing an Identifier from
Text (Section 4.2.8) from input_string. Text (Section 4.2.8) from input_string.
6. If param_name is already present in parameters, fail parsing. 6. If param_name is already present in parameters, fail parsing.
7. Let param_value be a null value. 7. Let param_value be a null value.
8. If the first character of input_string is "=": 8. If the first character of input_string is "=":
1. Consume the "=" character at the beginning of 1. Consume the "=" character at the beginning of
input_string. input_string.
skipping to change at page 19, line 45 skipping to change at page 20, line 11
5. If type is "integer" and input_number contains more than 19 5. If type is "integer" and input_number contains more than 19
characters, fail parsing. characters, fail parsing.
6. If type is "float" and input_number contains more than 16 6. If type is "float" and input_number contains more than 16
characters, fail parsing. characters, fail parsing.
8. If type is "integer": 8. If type is "integer":
1. Parse input_number as an integer and let output_number be 1. Parse input_number as an integer and let output_number be
the result. the product of the result and sign.
2. If output_number is outside the range defined in 2. If output_number is outside the range defined in
Section 3.5, fail parsing. Section 3.5, fail parsing.
9. Otherwise: 9. Otherwise:
1. If the final character of input_number is ".", fail parsing. 1. If the final character of input_number is ".", fail parsing.
2. Parse input_number as a float and let output_number be the 2. Parse input_number as a float and let output_number be the
result. product of the result and sign.
10. Return the product of output_number and sign. 10. Return output_number.
4.2.7. Parsing a String from Text 4.2.7. Parsing a String from Text
Given an ASCII string input_string, return an unquoted string. Given an ASCII string input_string, return an unquoted string.
input_string is modified to remove the parsed value. input_string is modified to remove the parsed value.
1. Let output_string be an empty string. 1. Let output_string be an empty string.
2. If the first character of input_string is not DQUOTE, fail 2. If the first character of input_string is not DQUOTE, fail
parsing. parsing.
skipping to change at page 20, line 43 skipping to change at page 21, line 10
1. Let next_char be the result of removing the first 1. Let next_char be the result of removing the first
character of input_string. character of input_string.
2. If next_char is not DQUOTE or "\", fail parsing. 2. If next_char is not DQUOTE or "\", fail parsing.
3. Append next_char to output_string. 3. Append next_char to output_string.
3. Else, if char is DQUOTE, return output_string. 3. Else, if char is DQUOTE, return output_string.
4. Else, if char is in the range %x00-1f or %x7f (i.e., is not 4. Else, if char is in the range %x00-1f or %x7f (i.e., is not
in VCHAR), fail parsing. in VCHAR or SP), fail parsing.
5. Else, append char to output_string. 5. Else, append char to output_string.
5. Otherwise, fail parsing. 5. Otherwise, fail parsing.
4.2.8. Parsing an Identifier from Text 4.2.8. Parsing an Identifier from Text
Given an ASCII string input_string, return a identifier. input_string Given an ASCII string input_string, return an identifier.
is modified to remove the parsed value. input_string is modified to remove the parsed value.
1. If the first character of input_string is not lcalpha, fail 1. If the first character of input_string is not lcalpha, fail
parsing. parsing.
2. Let output_string be an empty string. 2. Let output_string be an empty string.
3. While input_string is not empty: 3. While input_string is not empty:
1. Let char be the result of removing the first character of 1. Let char be the result of removing the first character of
input_string. input_string.
skipping to change at page 22, line 33 skipping to change at page 22, line 45
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 size of individual header fields as well as the overall
header block size to mitigate such attacks. header 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 Headers. 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
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
 End of changes. 28 change blocks. 
36 lines changed or deleted 50 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/