< draft-nottingham-http-browser-hints-02.txt   draft-nottingham-http-browser-hints-03.txt >
Network Working Group M. Nottingham Network Working Group M. Nottingham
Internet-Draft May 31, 2011 Internet-Draft June 20, 2012
Intended status: Informational Intended status: Informational
Expires: December 2, 2011 Expires: December 22, 2012
HTTP Browser Hints HTTP Browser Hints
draft-nottingham-http-browser-hints-02 draft-nottingham-http-browser-hints-03
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 December 2, 2011. This Internet-Draft will expire on December 22, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
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 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 . . . . . . . . . . . . . . . . . . . 5 5. Pre-defined Browser Hints . . . . . . . . . . . . . . . . . . 5
5.1. max-conns . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. max-conns . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. pconn-ip . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.2. pconn-ip . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. max-pipeline-depth . . . . . . . . . . . . . . . . . . . . 6 5.3. ip-balance . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. small-hdrs . . . . . . . . . . . . . . . . . . . . . . . . 6 5.4. connect-timeout . . . . . . . . . . . . . . . . . . . . . 6
5.5. relative-referer . . . . . . . . . . . . . . . . . . . . . 6 5.5. read-timeout . . . . . . . . . . . . . . . . . . . . . . . 6
5.6. chunk-req-bodies . . . . . . . . . . . . . . . . . . . . . 6 5.6. max-pipeline-depth . . . . . . . . . . . . . . . . . . . . 7
5.7. omit-cookies . . . . . . . . . . . . . . . . . . . . . . . 7 5.7. small-hdrs . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5.8. relative-referer . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 5.9. chunk-req-bodies . . . . . . . . . . . . . . . . . . . . . 7
7.1. The 'browser-hints' Well-Known URI . . . . . . . . . . . . 7 5.10. omit-cookies . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. The HTTP Browser Hints Registry . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.1. The 'browser-hints' Well-Known URI . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 8 7.2. The HTTP Browser Hints Registry . . . . . . . . . . . . . 8
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 6, line 18 skipping to change at page 6, line 18
In other words, if both www.example.com and foo.example.org resolve In other words, if both www.example.com and foo.example.org resolve
to the address 192.0.2.5, and indicate this hint, then clients can to the address 192.0.2.5, and indicate this hint, then clients can
send a request to www.example.com and then a request to send a request to www.example.com and then a request to
foo.example.org on the same TCP connection to that address. foo.example.org on the same TCP connection to that address.
If any of the sites grouped together for the purposes of pconn-ip If any of the sites grouped together for the purposes of pconn-ip
declare a max-conns hint, the max-conns value for that address is declare a max-conns hint, the max-conns value for that address is
considered to be the maximum of the declared max-conn hints present. considered to be the maximum of the declared max-conn hints present.
5.3. max-pipeline-depth 5.3. ip-balance
o Browser Hint Name: ip-balance
o Description: When present, this hint indicates a preferred policy
for clients to handle a DNS lookup that return multiple IPv4
addresses for the site.
o Value Type: string
o Contact: mnot@mnot.net
Defined values include:
o round-robin - Use each IP address in succession, using the next
address each time a new connection is opened.
o random - Use a random IP address from the list for each new
connection.
o failover - Use the first IP address, falling back to the following
address upon failure, and so forth.
o fastest - Attempt to connect to all IP addresses, using the
fastest for this and subsequent connections.
5.4. connect-timeout
o Browser Hint Name: connect-timeout
o Description: When present, this hint indicates how long the site
wishes browsers to wait for a connection to be established, in
seconds, before considering that connection unresponsive.
o Value Type: integer
o Contact: mnot@mnot.net
5.5. read-timeout
o Browser Hint Name: read-timeout
o Description: When present, this hint indicates how long the site
wishes browsers to wait before considering a connection
unresponsive, when data is outstanding (either a response or part
thereof), in seconds.
o Value Type: integer
o Contact: mnot@mnot.net
Note that requests on timed-out connections can be retried, subjects
to the constraints of HTTP.
5.6. max-pipeline-depth
o Browser Hint Name: max-pipeline-depth o Browser Hint Name: max-pipeline-depth
o Description: When present, this hint indicates the maximum number o Description: When present, this hint indicates the maximum number
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.7. 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 resource, and that they can use a shortened version of with the resource, and that they can use a shortened version of
the User-Agent header. the User-Agent header.
o Value Type: prefixlist o Value Type: prefixlist
o Contact: mnot@mnot.net o Contact: mnot@mnot.net
5.5. relative-referer 5.8. relative-referer
o Browser Hint Name: relative-referer o Browser Hint Name: relative-referer
o Description: When true, this hint indicates that servers prefer a o Description: When true, this hint indicates that servers prefer a
relative URI in the Referer request header. relative URI in the Referer request header.
o Value Type: true | false o Value Type: true | false
o Contact: mnot@mnot.net o Contact: mnot@mnot.net
5.6. chunk-req-bodies 5.9. 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.7. omit-cookies 5.10. omit-cookies
o Browser Hint Name: omit-cookies o Browser Hint Name: omit-cookies
o Description: When true, this hint indicates that cookies [RFC6265] o Description: When true, this hint indicates that cookies [RFC6265]
can be omitted in requests. can be omitted in requests.
o Value Type: prefixlist o Value Type: prefixlist
o Contact: mnot@mnot.net o Contact: mnot@mnot.net
6. Security Considerations 6. Security Considerations
TBD TBD
skipping to change at page 8, line 49 skipping to change at page 9, line 47
[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, Artur Bergman, Poul-Henning Kamp, Anirban
McManus, Steve Souders, and Martin Thompson for their suggestions and Kundu, Patrick McManus, Steve Souders, and Martin Thompson for their
feedback. 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. 13 change blocks. 
35 lines changed or deleted 81 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/