draft-ietf-httpbis-origin-frame-03.txt   draft-ietf-httpbis-origin-frame-latest.txt 
HTTP Working Group M. Nottingham HTTP Working Group M. Nottingham
Internet-Draft Internet-Draft
Intended status: Standards Track E. Nygren Intended status: Standards Track E. Nygren
Expires: October 22, 2017 Akamai Expires: December 23, 2017 Akamai
April 20, 2017 June 21, 2017
The ORIGIN HTTP/2 Frame The ORIGIN HTTP/2 Frame
draft-ietf-httpbis-origin-frame-03 draft-ietf-httpbis-origin-frame-latest
Abstract Abstract
This document specifies the ORIGIN frame for HTTP/2, to indicate what This document specifies the ORIGIN frame for HTTP/2, to indicate what
origins are available on a given connection. origins are available on a given connection.
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 42 skipping to change at page 1, line 42
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 October 22, 2017. This Internet-Draft will expire on December 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
5.1. Normative References . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 7 5.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Non-Normative Processing Algorithm . . . . . . . . . 7 Appendix A. Non-Normative Processing Algorithm . . . . . . . . . 7
Appendix B. Operational Considerations for Servers . . . . . . . 8 Appendix B. Operational Considerations for Servers . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
HTTP/2 [RFC7540] allows clients to coalesce different origins HTTP/2 [RFC7540] allows clients to coalesce different origins
[RFC6454] onto the same connection when certain conditions are met. [RFC6454] onto the same connection when certain conditions are met.
However, in certain cases, a connection is is not usable for a However, in certain cases, a connection is not usable for a coalesced
coalesced origin, so the 421 (Misdirected Request) status code origin, so the 421 (Misdirected Request) status code ([RFC7540],
([RFC7540], Section 9.1.2) was defined. Section 9.1.2) was defined.
Using a status code in this manner allows clients to recover from Using a status code in this manner allows clients to recover from
misdirected requests, but at the penalty of adding latency. To misdirected requests, but at the penalty of adding latency. To
address that, this specification defines a new HTTP/2 frame type, address that, this specification defines a new HTTP/2 frame type,
"ORIGIN", to allow servers to indicate what origins a connection is "ORIGIN", to allow servers to indicate what origins a connection is
usable for. usable for.
Additionally, experience has shown that HTTP/2's requirement to Additionally, experience has shown that HTTP/2's requirement to
establish server authority using both DNS and the server's establish server authority using both DNS and the server's
certificate is onerous. This specification relaxes the requirement certificate is onerous. This specification relaxes the requirement
skipping to change at page 5, line 23 skipping to change at page 5, line 23
[RFC7540] Section 9.1.1 explicitly allows a connection to be used for [RFC7540] Section 9.1.1 explicitly allows a connection to be used for
more than one origin server, if it is authoritative. This affects more than one origin server, if it is authoritative. This affects
what requests can be sent on the connection, both in HEADERS frame by what requests can be sent on the connection, both in HEADERS frame by
the client and as PUSH_PROMISE frames from the server. the client and as PUSH_PROMISE frames from the server.
Once an Origin Set has been initialised for a connection, clients Once an Origin Set has been initialised for a connection, clients
that implement this specification change these behaviors in the that implement this specification change these behaviors in the
following ways: following ways:
o Clients MUST NOT consult DNS to establish the connection's o Clients MUST NOT consult DNS to establish the connection's
authority for new requests. The TLS certificate MUST stil be used authority for new requests. The TLS certificate MUST still be
to do so, as described in [RFC7540] Section 9.1.1. used to do so, as described in [RFC7540] Section 9.1.1.
o Clients sending a new request SHOULD use an existing connection if o Clients sending a new request SHOULD use an existing connection if
the request's origin is in that connection's Origin Set, unless the request's origin is in that connection's Origin Set, unless
there are operational reasons for creating a new connection. there are operational reasons for creating a new connection.
o Clients MUST use the Origin Set to determine whether a received o Clients MUST use the Origin Set to determine whether a received
PUSH_PROMISE is authoritative, as described in [RFC7540], PUSH_PROMISE is authoritative, as described in [RFC7540],
Section 8.2.2. Section 8.2.2.
Note that clients are still required to perform checks on the Note that clients are still required to perform checks on the
certificate presented by the server for each origin that a connection certificate presented by the server for each origin that a connection
is used for; see [RFC7540] Section 9.1.1 for more information. This is used for; see [RFC7540] Section 9.1.1 for more information. This
includes verifying that the host matches a "dNSName" value from the includes verifying that the host matches a "dNSName" value from the
certificate "subjectAltName" field (using the wildcard rules defined certificate "subjectAltName" field (using the wildcard rules defined
in [RFC2818]; see also [RFC5280] Section 4.2.1.6). in [RFC2818]; see also [RFC5280] Section 4.2.1.6).
Because ORIGIN can change the set of origins a connection is used for Because ORIGIN can change the set of origins a connection is used for
over time, it is possible that a client might have more than one over time, it is possible that a client might have more than one
viable connection to an origin open at any time. When this occurs, viable connection to an origin open at any time. When this occurs,
clients SHOULD not emit new requests on any connection whose Origin clients SHOULD not emit new requests on any connection whose Origin
Set is a subset of another connection's Origin Set, and SHOULD close Set is a proper subset of another connection's Origin Set, and SHOULD
it once all outstanding requests are satisfied. close it once all outstanding requests are satisfied.
3. IANA Considerations 3. IANA Considerations
This specification adds an entry to the "HTTP/2 Frame Type" registry. This specification adds an entry to the "HTTP/2 Frame Type" registry.
o Frame Type: ORIGIN o Frame Type: ORIGIN
o Code: 0xc o Code: 0xc
o Specification: [this document] o Specification: [this document]
skipping to change at page 8, line 15 skipping to change at page 8, line 15
1. Parse "origin_raw" as an ASCII serialization of an origin 1. Parse "origin_raw" as an ASCII serialization of an origin
([RFC6454], Section 6.2) and let the result be ([RFC6454], Section 6.2) and let the result be
"parsed_origin". If parsing fails, skip to the next "parsed_origin". If parsing fails, skip to the next
"origin_raw". "origin_raw".
2. Add "parsed_origin" to the Origin Set. 2. Add "parsed_origin" to the Origin Set.
Appendix B. Operational Considerations for Servers Appendix B. Operational Considerations for Servers
The ORIGIN frame allows a server to indicate for which origins a The ORIGIN frame allows a server to indicate for which origins a
given connection ought be used. given connection ought be used. The set of origins advertised using
this mechanism is under control of the server; servers are not
obligated to use it, or to advertise all origins which they might be
able to answer a request for.
For example, it can be used to inform the client that the connection For example, it can be used to inform the client that the connection
is to only be used for the SNI-based origin, by sending an empty is to only be used for the SNI-based origin, by sending an empty
ORIGIN frame. Or, a larger number of origins can be indicated by ORIGIN frame. Or, a larger number of origins can be indicated by
including a payload. including a payload.
Generally, this information is most useful to send before sending any Generally, this information is most useful to send before sending any
part of a response that might initiate a new connection; for example, part of a response that might initiate a new connection; for example,
"Link" headers [RFC5988] in a response HEADERS, or links in the "Link" headers [RFC5988] in a response HEADERS, or links in the
response body. response body.
 End of changes. 7 change blocks. 
12 lines changed or deleted 15 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/