draft-ietf-httpbis-header-structure-00.txt   draft-ietf-httpbis-header-structure-01.txt 
HTTP Working Group P-H. Kamp HTTP Working Group P-H. Kamp
Internet-Draft The Varnish Cache Project Internet-Draft The Varnish Cache Project
Intended status: Standards Track December 10, 2016 Intended status: Standards Track April 24, 2017
Expires: June 13, 2017 Expires: October 26, 2017
HTTP Header Common Structure HTTP Header Common Structure
draft-ietf-httpbis-header-structure-00 draft-ietf-httpbis-header-structure-01
Abstract Abstract
An abstract data model for HTTP headers, "Common Structure", and a An abstract data model for HTTP headers, "Common Structure", and a
HTTP/1 serialization of it, generalized from current HTTP headers. HTTP/1 serialization of it, generalized from current HTTP headers.
Note to Readers Note to Readers
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 June 13, 2017. This Internet-Draft will expire on October 26, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 35 skipping to change at page 2, line 35
serialization from the data model. serialization from the data model.
During the development of HPACK it became evident that significantly During the development of HPACK it became evident that significantly
bigger gains were available if semantic compression could be used, bigger gains were available if semantic compression could be used,
most notably with timestamps. However, the lack of a common data most notably with timestamps. However, the lack of a common data
structure for HTTP headers would make semantic compression one long structure for HTTP headers would make semantic compression one long
list of special cases. list of special cases.
Parallel to this, various proposals for how to fulfill data- Parallel to this, various proposals for how to fulfill data-
transportation needs, and to a lesser degree to impose some kind of transportation needs, and to a lesser degree to impose some kind of
order on HTTP headers, at least going forward were floated. order on HTTP headers, at least going forward, were floated.
All of these proposals, JSON, CBOR etc. run into the same basic All of these proposals, JSON, CBOR etc. run into the same basic
problem: Their serialization is incompatible with [RFC7230]'s ABNF problem: Their serialization is incompatible with RFC 7230's
definition of 'field-value'. [RFC7230] ABNF definition of 'field-value'.
For binary formats, such as CBOR, a wholesale base64/85 For binary formats, such as CBOR, a wholesale base64/85
reserialization would be needed, with negative results for both reserialization would be needed, with negative results for both
debugability and bandwidth. debugability and bandwidth.
For textual formats, such as JSON, the format must first be neutered For textual formats, such as JSON, the format must first be neutered
to not violate field-value's ABNF, and then workarounds added to to not violate field-value's ABNF, and then workarounds added to
reintroduce the features just lost, for instance UNICODE strings, and reintroduce the features just lost, for instance UNICODE strings.
suddenly it is no longer JSON anymore.
The post-surgery format is no longer JSON, and it experience
indicates that almost-but-not-quite compatibility is worse than no
compatibility.
This proposal starts from the other end, and builds and generalizes a This proposal starts from the other end, and builds and generalizes a
data structure definition from existing HTTP headers, which means data structure definition from existing HTTP headers, which means
that HTTP/1 serialization and 'field-value' compatibility is built that HTTP/1 serialization and 'field-value' compatibility is built
in. in.
If all future HTTP headers are defined to fit into this Common If all future HTTP headers are defined to fit into this Common
Structure we have at least halted the proliferation of bespoke Structure we have at least halted the proliferation of bespoke
parsers and started to pave the road for semantic compression parsers and started to pave the road for semantic compression
serializations of HTTP traffic. serializations of HTTP traffic.
skipping to change at page 3, line 26 skipping to change at page 3, line 29
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2. Definition of HTTP Header Common Structure 2. Definition of HTTP Header Common Structure
The data model of Common Structure is an ordered sequence of named The data model of Common Structure is an ordered sequence of named
dictionaries. Please see Appendix A for how this model was derived. dictionaries. Please see Appendix A for how this model was derived.
The definition of the data model is on purpose abstract, uncoupled The definition of the data model is on purpose abstract, uncoupled
from any protocol serialization or programming environment from any protocol serialization or programming environment
representation, meant as the foundation on which all such representation, it is meant as the foundation on which all such
manifestations of the model can be built. manifestations of the model can be built.
Common Structure in ABNF: Common Structure in ABNF (Slightly bastardized relative to RFC5234
[RFC5234]):
import token from RFC7230 import token from RFC7230
import DIGIT from RFC5234 import DIGIT from RFC5234
common-structure = 1* ( identifier dictionary ) common-structure = 1* ( identifier dictionary )
dictionary = * ( identifier value ) dictionary = * ( identifier [ value ] )
value = identifier / value = identifier /
integer /
number / number /
ascii_string / ascii-string /
unicode_string / unicode-string /
blob / blob /
timestamp / timestamp /
common-structure common-structure
Recursion is included as a way to to support deep and more general
data structures, but its use is highly discouraged and where it is
used the depth of recursion SHALL always be explicitly limited in the
specifications of the HTTP headers which allow it.
identifier = token [ "/" token ] identifier = token [ "/" token ]
number = ["-"] 1*15 DIGIT integer = ["-"] 1*19 DIGIT
# XXX: Not sure how to do this in ABNF:
# XXX: A single "." allowed between any two digits
# The range is limited is to ensure it can be
# correctly represented in IEEE754 64 bit
# binary floating point format.
ascii_string = * %x20-7e Integers SHALL be in the range +/- 2^63-1 (= +/- 9223372036854775807)
# This is a "safe" string in the sense that it
# contains no control characters or multi-byte
# sequences. If that is not fancy enough, use
# unicode_string.
unicode_string = * unicode_codepoint number = ["-"] DIGIT '.' 1*14DIGIT /
# XXX: Is there a place to import this from ? ["-"] 2DIGIT '.' 1*13DIGIT /
# Unrestricted unicode, because there is no sane ["-"] 3DIGIT '.' 1*12DIGIT /
# way to restrict or otherwise make unicode "safe". ... /
["-"] 12DIGIT '.' 1*3DIGIT /
["-"] 13DIGIT '.' 1*2DIGIT /
["-"] 14DIGIT '.' 1DIGIT
The limit of 15 significant digits is chosen so that numbers can be
correctly represented by IEEE754 64 bit binary floating point.
ascii-string = * %x20-7e
This is intended to be an efficient, "safe" and uncomplicated string
type, for uses where the string content is culturally neutral or
where it will not be user visible.
unicode-string = * UNICODE
UNICODE = <U+0000-U+D7FF / U+E000-U+10FFFF>
# UNICODE nicked from draft-seantek-unicode-in-abnf-02
Unicode-strings are unrestricted because there is no sane and/or
culturally neutral way to subset or otherwise make unicode "safe",
and Unicode is still evolving new and interesting code points.
Users of unicode-string SHALL be prepared for the full gammut of
glyph-gymnastics in order to avoid U+1F4A9 U+08 U+1F574.
blob = * %0x00-ff blob = * %0x00-ff
# Intended for cryptographic data and as a general
# escape mechanism for unmet requirements.
timestamp = POSIX time_t with optional millisecond resolution Blobs are intended primarily for cryptographic data, but can be used
# XXX: Is there a place to import this from ? for any otherwise unsatisfied needs.
timestamp = number
A timestamp counts seconds since the UNIX time_t epoch, including the
"invisible leap-seconds" misfeature.
3. HTTP/1 Serialization of HTTP Header Common Structure 3. HTTP/1 Serialization of HTTP Header Common Structure
In ABNF: In ABNF:
import OWS from RFC7230 import OWS from RFC7230
import HEXDIG, DQUOTE from RFC5234 import HEXDIG, DQUOTE from RFC5234
import UTF8-2, UTF8-3, UTF8-4 from RFC3629 import EmbeddedUnicodeChar from RFC5137
h1_common-structure-header = h1-common-structure-header =
( field-name ":" OWS ">" h1_common_structure "<" ) h1-common-structure-legacy-header /
# Self-identifying HTTP headers h1-common-structure-self-identifying-header
( field-name ":" OWS h1_common_structure ) /
# legacy HTTP headers on white-list, see {{iana}}
h1_common_structure = h1_element * ("," h1_element) h1-common-structure-legacy-header =
field-name ":" OWS h1-common-structure
h1_element = identifier * (";" identifier ["=" h1_value]) Only white-listed legacy headers (see Section 8) can use this format.
h1_value = identifier / h1-common-structure-self-identifying-header:
field-name ":" OWS ">" h1-common-structure "<"
h1-common-structure = h1-element * ("," h1-element)
h1-element = identifier * (";" identifier ["=" h1-value])
h1-value = identifier /
integer /
number / number /
h1_ascii_string / h1-ascii-string /
h1_unicode_string / h1-unicode-string /
h1_blob / h1-blob /
h1_timestamp / h1-timestamp /
h1_common-structure ">" h1-common-structure "<"
h1_ascii_string = DQUOTE *( h1-ascii-string = DQUOTE *(
( "\" DQUOTE ) / ( "\" DQUOTE ) /
( "\" "\" ) / ( "\" "\" ) /
0x20-21 / 0x20-21 /
0x23-5B / 0x23-5B /
0x5D-7E 0x5D-7E
) DQUOTE ) DQUOTE
# This is a proper subset of h1_unicode_string
# NB only allowed backslash escapes are \" and \\
h1_unicode_string = DQUOTE *( h1-unicode-string = DQUOTE *(
( "\" DQUOTE ) ( "\" DQUOTE )
( "\" "\" ) / ( "\" "\" ) /
( "\" "u" 4*HEXDIG ) / EmbeddedUnicodeChar /
0x20-21 / 0x20-21 /
0x23-5B / 0x23-5B /
0x5D-7E / 0x5D-7E /
UTF8-2 /
UTF8-3 /
UTF8-4
) DQUOTE ) DQUOTE
# This is UTF8 with HTTP1 unfriendly codepoints
# (00-1f, 7f) neutered with \uXXXX escapes.
h1_blob = "'" base64 "'" The dim prospects of ever getting a majority of HTTP1 paths 8-bit
clean makes UTF-8 unviable as H1 serialization. Given that very
little of the information in HTTP headers is presented to users in
the first place, improving H1 and HPACK efficiency by inventing a
more efficient RFC5137 compliant escape-sequences seems unwarranted.
h1-blob = ":" base64 ":"
# XXX: where to import base64 from ? # XXX: where to import base64 from ?
h1_timestamp = number
# UNIX/POSIX time_t semantics.
# fractional seconds allowed.
h1_common_structure = ">" h1_common_structure "<" h1-timestamp = number
XXX: Allow OWS in parsers, but not in generators ? XXX: Allow OWS in parsers, but not in generators ?
In programming environments which do not define a native In programming environments which do not define a native
representation or serialization of Common Structure, the HTTP/1 representation or serialization of Common Structure, the HTTP/1
serialization should be used. serialization should be used.
4. When to use Common Structure Parser 4. When to use Common Structure Parser
All future standardized and all private HTTP headers using Common All future standardized and all private HTTP headers using Common
Structure should self identify as such. In the HTTP/1 serialization Structure should self identify as such. In the HTTP/1 serialization
by making the first character ">" and the last "<". (These two by making the first character ">" and the last "<". (These two
characters are deliberately "the wrong way" to not clash with characters are deliberately "the wrong way" to not clash with
skipping to change at page 7, line 47 skipping to change at page 8, line 43
in the new field. in the new field.
The RFC723x headers listed in Appendix A.5 will get the value "False" The RFC723x headers listed in Appendix A.5 will get the value "False"
in the new field. in the new field.
All other existing entries in the registry will be set to "Unknown" All other existing entries in the registry will be set to "Unknown"
until and if the owner of the entry requests otherwise. until and if the owner of the entry requests otherwise.
9. Security Considerations 9. Security Considerations
TBD Unique dictionary keys are required to reduce the risk of smuggling
attacks.
10. Normative References 10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC5137] Klensin, J., "ASCII Escaping of Unicode Characters",
BCP 137, RFC 5137, DOI 10.17487/RFC5137, February 2008,
<http://www.rfc-editor.org/info/rfc5137>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
10.2. Informative References
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
DOI 10.17487/RFC7232, June 2014,
<http://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, DOI 10.17487/RFC7233, June 2014,
<http://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235,
DOI 10.17487/RFC7235, June 2014,
<http://www.rfc-editor.org/info/rfc7235>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<http://www.rfc-editor.org/info/rfc7239>.
[RFC7694] Reschke, J., "Hypertext Transfer Protocol (HTTP) Client-
Initiated Content-Encoding", RFC 7694,
DOI 10.17487/RFC7694, November 2015,
<http://www.rfc-editor.org/info/rfc7694>.
Appendix A. Do HTTP headers have any common structure ? Appendix A. Do HTTP headers have any common structure ?
Several proposals have been floated in recent years to use some Several proposals have been floated in recent years to use some
preexisting structured data serialization or other for HTTP headers, preexisting structured data serialization or other for HTTP headers,
to impose some sanity. to impose some sanity.
None of these proposals have gained traction and no obvious candidate None of these proposals have gained traction and no obvious candidate
data serializations have been left unexamined. data serializations have been left unexamined.
This effort tries to tackle the question from the other side, by This effort tries to tackle the question from the other side, by
skipping to change at page 8, line 45 skipping to change at page 10, line 42
The majority of RFC723x HTTP headers are lists. A few of them are The majority of RFC723x HTTP headers are lists. A few of them are
ordered, ('Content-Encoding'), some are unordered ('Connection') and ordered, ('Content-Encoding'), some are unordered ('Connection') and
some are ordered by 'q=%f' weight parameters ('Accept') some are ordered by 'q=%f' weight parameters ('Accept')
In most cases, the list elements are some kind of identifier, usually In most cases, the list elements are some kind of identifier, usually
derived from ABNF 'token' as defined by [RFC7230]. derived from ABNF 'token' as defined by [RFC7230].
A subgroup of headers, mostly related to MIME, uses what one could A subgroup of headers, mostly related to MIME, uses what one could
call a 'qualified token':: call a 'qualified token'::
qualified_token = token_or_asterix [ "/" token_or_asterix ] qualified-token = token-or-asterix [ "/" token-or-asterix ]
The second motif is parameterized list elements. The best known is The second motif is parameterized list elements. The best known is
the "q=0.5" weight parameter, but other parameters exist as well. the "q=0.5" weight parameter, but other parameters exist as well.
Generalizing from these motifs, our candidate "Common Structure" data Generalizing from these motifs, our candidate "Common Structure" data
model becomes an ordered list of named dictionaries. model becomes an ordered list of named dictionaries.
In pidgin ABNF, ignoring white-space for the sake of clarity, the In pidgin ABNF, ignoring white-space for the sake of clarity, the
HTTP/1.1 serialization of Common Structure is is something like: HTTP/1.1 serialization of Common Structure is is something like:
token_or_asterix = token from {{RFC7230}}, but also allowing "*" token-or-asterix = token from RFC7230, but also allowing "*"
qualified_token = token_or_asterix [ "/" token_or_asterix ] qualified-token = token-or-asterix [ "/" token-or-asterix ]
field-name, see {{RFC7230}} field-name, see RFC7230
Common_Structure_Header = field-name ":" 1#named_dictionary Common-Structure-Header = field-name ":" 1#named-dictionary
named_dictionary = qualified_token [ *(";" param) ] named-dictionary = qualified-token [ *(";" param) ]
param = token [ "=" value ] param = token [ "=" value ]
value = we'll get back to this in a moment. value = we'll get back to this in a moment.
Nineteen out of the RFC723x's 48 headers, almost 40%, can already be Nineteen out of the RFC723x's 48 headers, almost 40%, can already be
parsed using this definition, and none the rest have requirements parsed using this definition, and none the rest have requirements
which could not be met by this data model. See Appendix A.4 and which could not be met by this data model. See Appendix A.4 and
Appendix A.5 for the full survey details. Appendix A.5 for the full survey details.
skipping to change at page 11, line 13 skipping to change at page 13, line 7
But history has been particularly unkind to that idea. But history has been particularly unkind to that idea.
Most attempts studied as part of this effort, have sunk under Most attempts studied as part of this effort, have sunk under
complexity caused by reaching for generality, but where scope has complexity caused by reaching for generality, but where scope has
been wisely limited, it seems to be possible. been wisely limited, it seems to be possible.
So file that idea under "future work". So file that idea under "future work".
A.4. RFC723x headers with "common structure" A.4. RFC723x headers with "common structure"
Accept [RFC7231, Section 5.3.2] o Accept [RFC7231], Section 5.3.2
Accept-Charset [RFC7231, Section 5.3.3]
Accept-Encoding [RFC7231, Section 5.3.4][RFC7694, Section 3] o Accept-Charset [RFC7231], Section 5.3.3
Accept-Language [RFC7231, Section 5.3.5]
Age [RFC7234, Section 5.1] o Accept-Encoding [RFC7231], Section 5.3.4, [RFC7694], Section 3
Allow [RFC7231, Section 7.4.1]
Connection [RFC7230, Section 6.1] o Accept-Language [RFC7231], Section 5.3.5
Content-Encoding [RFC7231, Section 3.1.2.2]
Content-Language [RFC7231, Section 3.1.3.2] o Age [RFC7234], Section 5.1
Content-Length [RFC7230, Section 3.3.2]
Content-Type [RFC7231, Section 3.1.1.5] o Allow [RFC7231], Section 7.4.1
Expect [RFC7231, Section 5.1.1]
Max-Forwards [RFC7231, Section 5.1.2] o Connection [RFC7230], Section 6.1
MIME-Version [RFC7231, Appendix A.1]
TE [RFC7230, Section 4.3] o Content-Encoding [RFC7231], Section 3.1.2.2
Trailer [RFC7230, Section 4.4]
Transfer-Encoding [RFC7230, Section 3.3.1] o Content-Language [RFC7231], Section 3.1.3.2
Upgrade [RFC7230, Section 6.7]
Vary [RFC7231, Section 7.1.4] o Content-Length [RFC7230], Section 3.3.2
o Content-Type [RFC7231], Section 3.1.1.5
o Expect [RFC7231], Section 5.1.1
o Max-Forwards [RFC7231], Section 5.1.2
o MIME-Version [RFC7231], Appendix A.1
o TE [RFC7230], Section 4.3
o Trailer [RFC7230], Section 4.4
o Transfer-Encoding [RFC7230], Section 3.3.1
o Upgrade [RFC7230], Section 6.7
o Vary [RFC7231], Section 7.1.4
A.5. RFC723x headers with "uncommon structure" A.5. RFC723x headers with "uncommon structure"
1 of the RFC723x headers is only reserved, and therefore have no 1 of the RFC723x headers is only reserved, and therefore have no
structure at all: structure at all:
Close [RFC7230, Section 8.1] o Close [RFC7230], Section 8.1
5 of the RFC723x headers are HTTP dates: 5 of the RFC723x headers are HTTP dates:
Date [RFC7231, Section 7.1.1.2] o Date [RFC7231], Section 7.1.1.2
Expires [RFC7234, Section 5.3]
If-Modified-Since [RFC7232, Section 3.3] o Expires [RFC7234], Section 5.3
If-Unmodified-Since [RFC7232, Section 3.4]
Last-Modified [RFC7232, Section 2.2] o If-Modified-Since [RFC7232], Section 3.3
o If-Unmodified-Since [RFC7232], Section 3.4
o Last-Modified [RFC7232], Section 2.2
24 of the RFC723x headers use bespoke formats which only a single or 24 of the RFC723x headers use bespoke formats which only a single or
in rare cases two headers share: in rare cases two headers share:
Accept-Ranges [RFC7233, Section 2.3] o Accept-Ranges [RFC7233], Section 2.3
bytes-unit / other-range-unit
Authorization [RFC7235, Section 4.2] * bytes-unit / other-range-unit
Proxy-Authorization [RFC7235, Section 4.4]
credentials
Cache-Control [RFC7234, Section 5.2] o Authorization [RFC7235], Section 4.2
1#cache-directive
Content-Location [RFC7231, Section 3.1.4.2] o Proxy-Authorization [RFC7235], Section 4.4
absolute-URI / partial-URI
Content-Range [RFC7233, Section 4.2] * credentials
byte-content-range / other-content-range
ETag [RFC7232, Section 2.3] o Cache-Control [RFC7234], Section 5.2
entity-tag
Forwarded [RFC7239] * 1#cache-directive
1#forwarded-element
From [RFC7231, Section 5.5.1] o Content-Location [RFC7231], Section 3.1.4.2
mailbox
If-Match [RFC7232, Section 3.1] * absolute-URI / partial-URI
If-None-Match [RFC7232, Section 3.2]
"*" / 1#entity-tag
If-Range [RFC7233, Section 3.2] o Content-Range [RFC7233], Section 4.2
entity-tag / HTTP-date
Host [RFC7230, Section 5.4] * byte-content-range / other-content-range
uri-host [ ":" port ]
Location [RFC7231, Section 7.1.2] o ETag [RFC7232], Section 2.3
URI-reference
Pragma [RFC7234, Section 5.4] * entity-tag
1#pragma-directive
Range [RFC7233, Section 3.1] o Forwarded [RFC7239]
byte-ranges-specifier / other-ranges-specifier
Referer [RFC7231, Section 5.5.2] * 1#forwarded-element
absolute-URI / partial-URI
Retry-After [RFC7231, Section 7.1.3] o From [RFC7231], Section 5.5.1
HTTP-date / delay-seconds
Server [RFC7231, Section 7.4.2] * mailbox
User-Agent [RFC7231, Section 5.5.3]
product *( RWS ( product / comment ) )
Via [RFC7230, Section 5.7.1] o If-Match [RFC7232], Section 3.1
1#( received-protocol RWS received-by [ RWS comment ] ) o If-None-Match [RFC7232], Section 3.2
Warning [RFC7234, Section 5.5] * "*" / 1#entity-tag
1#warning-value
Proxy-Authenticate [RFC7235, Section 4.3] o If-Range [RFC7233], Section 3.2
WWW-Authenticate [RFC7235, Section 4.1]
1#challenge * entity-tag / HTTP-date
o Host [RFC7230], Section 5.4
* uri-host [ ":" port ]
o Location [RFC7231], Section 7.1.2
* URI-reference
o Pragma [RFC7234], Section 5.4
* 1#pragma-directive
o Range [RFC7233], Section 3.1
* byte-ranges-specifier / other-ranges-specifier
o Referer [RFC7231], Section 5.5.2
* absolute-URI / partial-URI
o Retry-After [RFC7231], Section 7.1.3
* HTTP-date / delay-seconds
o Server [RFC7231], Section 7.4.2
o User-Agent [RFC7231], Section 5.5.3
* product *( RWS ( product / comment ) )
o Via [RFC7230], Section 5.7.1
* 1#( received-protocol RWS received-by [ RWS comment ] )
o Warning [RFC7234], Section 5.5
* 1#warning-value
o Proxy-Authenticate [RFC7235], Section 4.3
o WWW-Authenticate [RFC7235], Section 4.1
* 1#challenge
Appendix B. Changes
B.1. Since draft-ietf-httpbis-header-structure-00
Added signed 64bit integer type.
Drop UTF8, and settle on BCP137 [RFC5137]::EmbeddedUnicodeChar for
h1-unicode-string.
Change h1_blob delimiter to ":" since "'" is valid t_char
Author's Address Author's Address
Poul-Henning Kamp Poul-Henning Kamp
The Varnish Cache Project The Varnish Cache Project
Email: phk@varnish-cache.org Email: phk@varnish-cache.org
 End of changes. 67 change blocks. 
141 lines changed or deleted 273 lines changed or added

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