< draft-nottingham-http-browser-hints-01.txt		draft-nottingham-http-browser-hints-02.txt >
	Network Working Group M. Nottingham		Network Working Group M. Nottingham
	Internet-Draft May 27, 2011		Internet-Draft May 31, 2011
	Intended status: Informational		Intended status: Informational
	Expires: November 28, 2011		Expires: December 2, 2011
	HTTP Browser Hints		HTTP Browser Hints
	draft-nottingham-http-browser-hints-01		draft-nottingham-http-browser-hints-02
	Abstract		Abstract
	Over time, Web browsers have adapted how they use HTTP based upon		Over time, Web browsers have adapted how they use HTTP based upon
	common server configurations and behaviours. While this is necessary		common server configurations and behaviours. While this is necessary
	in the common case, it can be detrimental for performance and		in the common case, it can be detrimental for performance and
	interoperability.		interoperability.
	This document establishes a mechanism whereby origin servers can make		This document establishes a mechanism whereby origin servers can make
	available hints for browsers about their preferences and		available hints for browsers about their preferences and
	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 November 28, 2011.		This Internet-Draft will expire on December 2, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. A file format for Browser Hints . . . . . . . . . . . . . . . . 3		3. A file format for Browser Hints . . . . . . . . . . . . . . . . 3
			3.1. The 'prefixlist' Value Type . . . . . . . . . . . . . . . . 4
	4. Discovering Browser Hints for a Web site . . . . . . . . . . . 4		4. Discovering Browser Hints for a Web site . . . . . . . . . . . 4
	5. Pre-defined Browser Hints . . . . . . . . . . . . . . . . . . . 4		5. Pre-defined Browser Hints . . . . . . . . . . . . . . . . . . . 5
	5.1. max-conns . . . . . . . . . . . . . . . . . . . . . . . . . 4		5.1. max-conns . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.2. pconn-ip . . . . . . . . . . . . . . . . . . . . . . . . . 5		5.2. pconn-ip . . . . . . . . . . . . . . . . . . . . . . . . . 5
	5.3. max-pipeline-depth . . . . . . . . . . . . . . . . . . . . 5		5.3. max-pipeline-depth . . . . . . . . . . . . . . . . . . . . 6
	5.4. small-hdrs . . . . . . . . . . . . . . . . . . . . . . . . 5		5.4. small-hdrs . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.5. no-referer . . . . . . . . . . . . . . . . . . . . . . . . 5		5.5. relative-referer . . . . . . . . . . . . . . . . . . . . . 6
	5.6. send-ref . . . . . . . . . . . . . . . . . . . . . . . . . 6		5.6. chunk-req-bodies . . . . . . . . . . . . . . . . . . . . . 6
	5.7. chunk-req-bodies . . . . . . . . . . . . . . . . . . . . . 6		5.7. omit-cookies . . . . . . . . . . . . . . . . . . . . . . . 7
	5.8. omit-cookies . . . . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
	6. The Ref HTTP Request Header . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		7.1. The 'browser-hints' Well-Known URI . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		7.2. The HTTP Browser Hints Registry . . . . . . . . . . . . . . 7
	8.1. The 'browser-hints' Well-Known URI . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8.2. The HTTP Browser Hints Registry . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	9.2. Informative References . . . . . . . . . . . . . . . . . . 8
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	HTTP [RFC2616] clients -- especially browsers -- typically use		HTTP [RFC2616] clients -- especially browsers -- typically use
	hardcoded values or heuristics to determine how many TCP connections		hardcoded values or heuristics to determine how many TCP connections
	to use to a server, based on common-case server behaviours and		to use to a server, based on common-case server behaviours and
	limitations.		limitations.
	Likewise, they often send voluminous request headers (e.g., in User-		Likewise, they often send voluminous request headers (e.g., in User-
	Agent and Allow) because they fear that changing those headers'		Agent and Allow) because they fear that changing those headers'
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	2. Requirements		2. Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. A file format for Browser Hints		3. A file format for Browser Hints
	Browser hints are indicating using a JSON [RFC4627] formatted file,		Browser hints are indicating using a JSON [RFC4627] formatted file,
	containing a single object whose member's names are browser hints, as		containing a single object whose member's names are browser hints, as
	defined by the registry Section 8.2.		defined by the registry Section 7.2.
	For example;		For example;
	{		{
	"max-conns": 5,		"max-conns": 5,
	"small-hdrs": true		"small-hdrs": true
	}		}
	By their nature, all browser hints are optional; i.e., browsers are		By their nature, all browser hints are optional; i.e., browsers are
	free to ignore them.		free to ignore them.
			3.1. The 'prefixlist' Value Type
			Each browser hint is defined to have a JSON-derived value type; e.g.,
			'string' or 'array'. This section defines a special value type,
			'prefixlist' that is an array containing one or more arrays, each
			containing a path prefix followed by either 'true' or 'false' to
			indicate whether the hint applies to that path.
			Prefixlists are evaluated in order, with the first case-sensitive,
			character-by-character prefix match for a given URI's path
			determining whether the hint applies.
			For example, given the following hint document:
			{
			"omit-cookies": [
			["/images/users/", false],
			["/images/", true]
			]
			}
			We can tell that "omit-cookies" applies to resources under the
			"/images/" path (such as "/images/123.jpg"), except for those under
			"/images/users/" (such as "/images/users/bob.jpg").
			If a value specified to be a prefixlist is either 'true' or 'false'
			that indicates that the hint applies to the whole site, or does not
			apply to the whole site, respectively.
			For example,
			{
			"omit-cookies": true
			}
			Indicates that the "omit-cookies" hint applies to the entire site.
			Prefixlists can only be used when the browser hint's registration
			nominates their use.
	4. Discovering Browser Hints for a Web site		4. Discovering Browser Hints for a Web site
	The hints relevant to a given site can be determined by fetching the		The hints relevant to a given site can be determined by fetching the
	URI path "/.well-known/browser-hints" for that site.		URI path "/.well-known/browser-hints" for that site.
	Typically, clients (especially browsers) will not block other		Typically, clients (especially browsers) will not block other
	requests to a site while fetching the browser hints (because they're		requests to a site while fetching the browser hints (because they're
	optional); instead, it will usually be done concurrently with other		optional); instead, it will usually be done concurrently with other
	requests, or on idle connections for future use.		requests, or on idle connections for future use.
	skipping to change at page 4, line 33 ¶		skipping to change at page 5, line 25 ¶
	o https://foo.com/		o https://foo.com/
	o http://foo.com:8000/		o http://foo.com:8000/
	o http://www.foo.com/		o http://www.foo.com/
	Clients SHOULD follow HTTP 3xx redirects when retrieving hints.		Clients SHOULD follow HTTP 3xx redirects when retrieving hints.
	A successful response is valid for its associated site for as long as		A successful response is valid for its associated site for as long as
	it can be cached in HTTP.		it can be cached in HTTP.
	If the response has a 200 status code but no explicit freshness		If the response has a 200 status code but no explicit freshness
	(e.g., a Cache-Control: max-age or Expires: header), browsers SHOULD		(e.g., a Cache-Control: max-age or Expires: header), clients SHOULD
	cache the response heuristically for a generous fixed period (e.g.,		cache the response heuristically for a generous fixed period (e.g.,
	30 days).		14 days).
			If the response has a 404 status code but no explicit freshness,
			clients SHOULD cache the response heuristically for a generous fixed
			period (e.g., 14 days).
	5. Pre-defined Browser Hints		5. Pre-defined Browser Hints
	5.1. max-conns		5.1. max-conns
	o Browser Hint Name: max-conns		o Browser Hint Name: max-conns
	o Description: When present, this hint indicates the maximum number		o Description: When present, this hint indicates the maximum number
	of concurrent persistent connections that the site would like		of concurrent persistent connections that the site would like
	clients to use.		clients to use.
	o Value Type: number		o Value Type: number
	skipping to change at page 5, line 41 ¶		skipping to change at page 6, line 32 ¶
	of pipelined requests per connection that the site would like		of pipelined requests per connection that the site would like
	clients to use.		clients to use.
	o Value Type: number		o Value Type: number
	o Contact: mnot@mnot.net		o Contact: mnot@mnot.net
	5.4. small-hdrs		5.4. small-hdrs
	o Browser Hint Name: small-hdrs		o Browser Hint Name: small-hdrs
	o Description: When true, this hint indicates that clients can omit		o Description: When true, this hint indicates that clients can omit
	the Accept and Accept-Charset request headers when communicating		the Accept and Accept-Charset request headers when communicating
	with the site, and that they can use a shortened version of the		with the resource, and that they can use a shortened version of
	User-Agent header.		the User-Agent header.
	o Value Type: true | false		o Value Type: prefixlist
	o Contact: mnot@mnot.net
	5.5. no-referer
	o Browser Hint Name: no-referer
	o Description: When true, this hint indicates that clients can omit
	the Referer HTTP request header when sending requests to the site.
	o Value Type: true | false
	o Contact: mnot@mnot.net		o Contact: mnot@mnot.net
	5.6. send-ref		5.5. relative-referer
	o Browser Hint Name: send-ref		o Browser Hint Name: relative-referer
	o Description: When true, this hint indicates that clients can omit		o Description: When true, this hint indicates that servers prefer a
	the Referer HTTP request header when sending requests to the site,		relative URI in the Referer request header.
	if they instead send a Ref HTTP request header (see Section 6).
	o Value Type: true | false		o Value Type: true | false
	o Contact: mnot@mnot.net		o Contact: mnot@mnot.net
	5.7. chunk-req-bodies		5.6. chunk-req-bodies
	o Browser Hint Name: chunk-req-bodies		o Browser Hint Name: chunk-req-bodies
	o Description: When true, this hint indicates that the server can		o Description: When true, this hint indicates that the server can
	successfully process a request with a chunk-encoded body; i.e.,		successfully process a request with a chunk-encoded body; i.e.,
	that it should not return a 411 Length Required status. Note that		that it should not return a 411 Length Required status. Note that
	clients may still require a 411 response status, even in when this		clients may still require a 411 response status, even in when this
	hint is present. When false, the server may or may not require a		hint is present. When false, the server may or may not require a
	Content-Length on requests with bodies.		Content-Length on requests with bodies.
	o Value Type: true | false		o Value Type: true | false
	o Contact: mnot@mnot.net		o Contact: mnot@mnot.net
	5.8. omit-cookies		5.7. omit-cookies
	o Browser Hint Name: omit-cookies		o Browser Hint Name: omit-cookies
	o Description: This hint contains a list of cookie [RFC6265] cookie-		o Description: When true, this hint indicates that cookies [RFC6265]
	names which can be omitted in requests sent to this site.		can be omitted in requests.
	o Value Type: Array of strings		o Value Type: prefixlist
	o Contact: mnot@mnot.net		o Contact: mnot@mnot.net
	6. The Ref HTTP Request Header		6. Security Considerations
	TBD: relative URI referer header
	7. Security Considerations
	TBD		TBD
	8. IANA Considerations		7. IANA Considerations
	8.1. The 'browser-hints' Well-Known URI
			7.1. The 'browser-hints' Well-Known URI
	This document defines the "browser-hints" Well-Known URI [RFC5785].		This document defines the "browser-hints" Well-Known URI [RFC5785].
	o URI suffix: browser-hints		o URI suffix: browser-hints
	o Change controller: mnot@mnot.net		o Change controller: mnot@mnot.net
	o Specification document(s): [this document]		o Specification document(s): [this document]
	o Related information:		o Related information:
	8.2. The HTTP Browser Hints Registry		7.2. The HTTP Browser Hints Registry
	This document establishes the HTTP Browser Hints Registry.		This document establishes the HTTP Browser Hints Registry.
	New hints are registered First Come First Served (see [RFC5226]), by		New hints are registered First Come First Served (see [RFC5226]), by
	sending e-mail to <mailto:iana@iana.org> (or using other mechanisms,		sending e-mail to <mailto:iana@iana.org> (or using other mechanisms,
	as established by IANA).		as established by IANA).
	Registration requests MUST use the following template:		Registration requests MUST use the following template:
	o Browser Hint Name: [name of hint]		o Browser Hint Name: [name of hint]
	skipping to change at page 7, line 44 ¶		skipping to change at page 8, line 17 ¶
	large. However, note that non-browser clients MAY use them.		large. However, note that non-browser clients MAY use them.
	Finally, new hints MUST NOT make communication non-conformant with		Finally, new hints MUST NOT make communication non-conformant with
	HTTP itself; i.e., this is not a mechanism for changing the HTTP		HTTP itself; i.e., this is not a mechanism for changing the HTTP
	protocol in incompatible ways. For example, if a hint indicates that		protocol in incompatible ways. For example, if a hint indicates that
	browsers can compress request headers using GZIP, intermediaries that		browsers can compress request headers using GZIP, intermediaries that
	are interposed are likely to fail.		are interposed are likely to fail.
	The initial contents of the registry are defined in Section 5.		The initial contents of the registry are defined in Section 5.
	9. References		8. References
	9.1. Normative References		8.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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC4627] Crockford, D., "The application/json Media Type for		[RFC4627] Crockford, D., "The application/json Media Type for
	JavaScript Object Notation (JSON)", RFC 4627, July 2006.		JavaScript Object Notation (JSON)", RFC 4627, July 2006.
	9.2. Informative References		8.2. Informative References
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,
	April 2010.		April 2010.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		April 2011.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	Thanks to Mike Belshe, Poul-Henning Kamp, Anirban Kundu, Patrick		Thanks to Mike Belshe, Poul-Henning Kamp, Anirban Kundu, Patrick
	McManus, and Steve Souders for their suggestions and feedback.		McManus, Steve Souders, and Martin Thompson for their suggestions and
			feedback.
	The author takes all responsibility for errors and omissions.		The author takes all responsibility for errors and omissions.
	Author's Address		Author's Address
	Mark Nottingham		Mark Nottingham
	Email: mnot@mnot.net		Email: mnot@mnot.net
	URI: http://www.mnot.net/		URI: http://www.mnot.net/
End of changes. 25 change blocks.
	58 lines changed or deleted		89 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/