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/