draft-ietf-httpbis-origin-frame-03.txt | draft-ietf-httpbis-origin-frame-04.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: February 24, 2018 Akamai | |||
April 20, 2017 | August 23, 2017 | |||
The ORIGIN HTTP/2 Frame | The ORIGIN HTTP/2 Frame | |||
draft-ietf-httpbis-origin-frame-03 | draft-ietf-httpbis-origin-frame-04 | |||
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 | |||
https://lists.w3.org/Archives/Public/ietf-http-wg/ . | https://lists.w3.org/Archives/Public/ietf-http-wg/. | |||
Working Group information can be found at http://httpwg.github.io/ ; | Working Group information can be found at http://httpwg.github.io/; | |||
source code and issues list for this draft can be found at | source code and issues list for this draft can be found at | |||
https://github.com/httpwg/http-extensions/labels/origin-frame . | https://github.com/httpwg/http-extensions/labels/origin-frame. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 February 24, 2018. | |||
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 26 ¶ | skipping to change at page 2, line 26 ¶ | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | |||
2. The ORIGIN HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 3 | 2. The ORIGIN HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. Processing ORIGIN Frames . . . . . . . . . . . . . . . . 3 | 2.2. Processing ORIGIN Frames . . . . . . . . . . . . . . . . 3 | |||
2.3. The Origin Set . . . . . . . . . . . . . . . . . . . . . 4 | 2.3. The Origin Set . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.4. Authority, Push and Coalescing with ORIGIN . . . . . . . 5 | 2.4. Authority, Push and Coalescing with ORIGIN . . . . . . . 5 | |||
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
5.1. Normative References . . . . . . . . . . . . . . . . . . 6 | 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
5.2. Informative References . . . . . . . . . . . . . . . . . 7 | 5.2. Informative References . . . . . . . . . . . . . . . . . 8 | |||
Appendix A. Non-Normative Processing Algorithm . . . . . . . . . 7 | Appendix A. Non-Normative Processing Algorithm . . . . . . . . . 8 | |||
Appendix B. Operational Considerations for Servers . . . . . . . 8 | Appendix B. Operational Considerations for Servers . . . . . . . 9 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
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 | |||
to check DNS when the ORIGIN frame is in use. Doing so has | to check DNS when the ORIGIN frame is in use. Doing so has | |||
additional benefits, such as removing the latency associated with | additional benefits, such as removing the latency associated with | |||
some DNS lookups, and improving DNS privacy. | some DNS lookups. | |||
1.1. Notational Conventions | 1.1. Notational Conventions | |||
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]. | |||
2. The ORIGIN HTTP/2 Frame | 2. The ORIGIN HTTP/2 Frame | |||
The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to | The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to | |||
indicate what origin(s) [RFC6454] the server would like the client to | indicate what origin(s) [RFC6454] the server would like the client to | |||
consider as members of the Origin Set (Section 2.3) for the | consider as members of the Origin Set (Section 2.3) for the | |||
connection it occurs within. | connection it occurs within. | |||
2.1. Syntax | 2.1. Syntax | |||
The ORIGIN frame type is 0xc (decimal 12). | The ORIGIN frame type is 0xc (decimal 12), and contains zero to many | |||
Origin-Entry. | ||||
+-------------------------------+-------------------------------+ | +-------------------------------+-------------------------------+ | |||
| Origin-Len (16) | ASCII-Origin? (*) ... | | Origin-Entry (*) ... | |||
+-------------------------------+-------------------------------+ | +-------------------------------+-------------------------------+ | |||
The ORIGIN frame's payload contains the following fields, sets of | An Origin-Entry is a length-delimited string: | |||
which may be repeated within the frame to indicate multiple origins: | ||||
+-------------------------------+-------------------------------+ | ||||
| Origin-Len (16) | ASCII-Origin? ... | ||||
+-------------------------------+-------------------------------+ | ||||
Specifically: | ||||
Origin-Len: An unsigned, 16-bit integer indicating the length, in | Origin-Len: An unsigned, 16-bit integer indicating the length, in | |||
octets, of the ASCII-Origin field. | octets, of the ASCII-Origin field. | |||
Origin: An optional sequence of characters containing the ASCII | Origin: An OPTIONAL sequence of characters containing the ASCII | |||
serialization of an origin ([RFC6454], Section 6.2) that the | serialization of an origin ([RFC6454], Section 6.2) that the | |||
sender believes this connection is or could be authoritative for. | sender believes this connection is or could be authoritative for. | |||
The ORIGIN frame does not define any flags. However, future updates | The ORIGIN frame does not define any flags. However, future updates | |||
to this specification MAY define flags. See Section 2.2. | to this specification MAY define flags. See Section 2.2. | |||
2.2. Processing ORIGIN Frames | 2.2. Processing ORIGIN Frames | |||
The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints | The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints | |||
that do not support this frame can safely ignore it upon receipt. | that do not support this frame can safely ignore it upon receipt. | |||
skipping to change at page 4, line 33 ¶ | skipping to change at page 4, line 39 ¶ | |||
parsing fails, the field MUST be ignored. | parsing fails, the field MUST be ignored. | |||
See Appendix A for an illustrative algorithm for processing ORIGIN | See Appendix A for an illustrative algorithm for processing ORIGIN | |||
frames. | frames. | |||
2.3. The Origin Set | 2.3. The Origin Set | |||
The set of origins (as per [RFC6454]) that a given connection might | The set of origins (as per [RFC6454]) that a given connection might | |||
be used for is known in this specification as the Origin Set. | be used for is known in this specification as the Origin Set. | |||
By default, a connections's Origin Set is uninitialised. When an | By default, the Origin Set for a connection is uninitialised. When | |||
ORIGIN frame is first received and successfully processed by a | an ORIGIN frame is first received and successfully processed by a | |||
client, the connection's Origin Set is defined to contain a single | client, the connection's Origin Set is defined to contain an initial | |||
origin, composed from: | origin. The initial origin is composed from: | |||
o Scheme: "https" | o Scheme: "https" | |||
o Host: the value sent in Server Name Indication ([RFC6066] | o Host: the value sent in Server Name Indication (SNI, [RFC6066] | |||
Section 3), converted to lower case | Section 3), converted to lower case | |||
o Port: the remote port of the connection (i.e., the server's port) | o Port: the remote port of the connection (i.e., the server's port) | |||
The contents of that ORIGIN frame (and subsequent ones) allows the | The contents of that ORIGIN frame (and subsequent ones) allows the | |||
server to incrementally add new origins to the Origin Set, as | server to incrementally add new origins to the Origin Set, as | |||
described in Section 2.2. | described in Section 2.2. | |||
The Origin Set is also affected by the 421 (Misdirected Request) | The Origin Set is also affected by the 421 (Misdirected Request) | |||
response status code, defined in [RFC7540] Section 9.1.2. Upon | response status code, defined in [RFC7540] Section 9.1.2. Upon | |||
receipt of a response with this status code, implementing clients | receipt of a response with this status code, implementing clients | |||
MUST create the ASCII serialisation of the corresponding request's | MUST create the ASCII serialisation of the corresponding request's | |||
origin (as per [RFC6454], Section 6.2) and remove it from the | origin (as per [RFC6454], Section 6.2) and remove it from the | |||
connection's Origin Set, if present. | connection's Origin Set, if present. | |||
skipping to change at page 5, line 8 ¶ | skipping to change at page 5, line 15 ¶ | |||
server to incrementally add new origins to the Origin Set, as | server to incrementally add new origins to the Origin Set, as | |||
described in Section 2.2. | described in Section 2.2. | |||
The Origin Set is also affected by the 421 (Misdirected Request) | The Origin Set is also affected by the 421 (Misdirected Request) | |||
response status code, defined in [RFC7540] Section 9.1.2. Upon | response status code, defined in [RFC7540] Section 9.1.2. Upon | |||
receipt of a response with this status code, implementing clients | receipt of a response with this status code, implementing clients | |||
MUST create the ASCII serialisation of the corresponding request's | MUST create the ASCII serialisation of the corresponding request's | |||
origin (as per [RFC6454], Section 6.2) and remove it from the | origin (as per [RFC6454], Section 6.2) and remove it from the | |||
connection's Origin Set, if present. | connection's Origin Set, if present. | |||
Note: When sending an ORIGIN frame to a connection that is | ||||
initialised as an Alternative Service [RFC7838], the initial | ||||
origin set Section 2.3 will contain an origin with the appropriate | ||||
scheme and hostname (since Alternative Services specifies that the | ||||
origin's hostname be sent in SNI). However, it is possible that | ||||
the port will be different than that of the intended origin, since | ||||
the initial origin set is calculated using the actual port in use, | ||||
which can be different for the alternative service. In this case, | ||||
the intended origin needs to be sent in the ORIGIN frame | ||||
explicitly. | ||||
For example, a client making requests for "https://example.com" is | ||||
directed to an alternative service at ("h2", "x.example.net", | ||||
"8443"). If this alternative service sends an ORIGIN frame, the | ||||
initial origin will be "https://example.com:8443". The client | ||||
will not be able to use the alternative service to make requests | ||||
for "https://example.com" unless that origin is explicitly | ||||
included in the ORIGIN frame. | ||||
2.4. Authority, Push and Coalescing with ORIGIN | 2.4. Authority, Push and Coalescing with ORIGIN | |||
[RFC7540], Section 10.1 uses both DNS and the presented TLS | [RFC7540], Section 10.1 uses both DNS and the presented TLS | |||
certificate to establish the origin server(s) that a connection is | certificate to establish the origin server(s) that a connection is | |||
authoritative for, just as HTTP/1.1 does in [RFC7230]. Furthermore, | authoritative for, just as HTTP/1.1 does in [RFC7230]. | |||
[RFC7540] Section 9.1.1 explicitly allows a connection to be used for | ||||
more than one origin server, if it is authoritative. This affects | ||||
what requests can be sent on the connection, both in HEADERS frame by | ||||
the client and as PUSH_PROMISE frames from the server. | ||||
Once an Origin Set has been initialised for a connection, clients | ||||
that implement this specification change these behaviors in the | ||||
following ways: | ||||
o Clients MUST NOT consult DNS to establish the connection's | Furthermore, [RFC7540] Section 9.1.1 explicitly allows a connection | |||
authority for new requests. The TLS certificate MUST stil be used | to be used for more than one origin server, if it is authoritative. | |||
to do so, as described in [RFC7540] Section 9.1.1. | This affects what requests can be sent on the connection, both in | |||
HEADERS frame by the client and as PUSH_PROMISE frames from the | ||||
server ([RFC7540], Section 8.2.2). | ||||
o Clients sending a new request SHOULD use an existing connection if | Once an Origin Set has been initialised for a connection, clients | |||
the request's origin is in that connection's Origin Set, unless | that implement this specification use it to help determine what the | |||
there are operational reasons for creating a new connection. | connection is authoritative for. Specifically, such clients MUST NOT | |||
consider a connection to be authoritative for an origin not present | ||||
in the Origin Set, and SHOULD use the connection for all requests to | ||||
origins in the Origin Set for which the connection is authoritative, | ||||
unless there are operational reasons for opening a new connection. | ||||
o Clients MUST use the Origin Set to determine whether a received | Note that for a connection to be considered authoritative for a given | |||
PUSH_PROMISE is authoritative, as described in [RFC7540], | origin, the client is still required to obtain a certificate that | |||
Section 8.2.2. | passes suitable checks; see [RFC7540] Section 9.1.1 for more | |||
information. This includes verifying that the host matches a | ||||
"dNSName" value from the certificate "subjectAltName" field (using | ||||
the wildcard rules defined in [RFC2818]; see also [RFC5280] | ||||
Section 4.2.1.6). | ||||
Note that clients are still required to perform checks on the | Additionally, clients MAY avoid consulting DNS to establish the | |||
certificate presented by the server for each origin that a connection | connection's authority for new requests; however, those that do so | |||
is used for; see [RFC7540] Section 9.1.1 for more information. This | face new risks, as explained in Section 4 | |||
includes verifying that the host matches a "dNSName" value from the | ||||
certificate "subjectAltName" field (using the wildcard rules defined | ||||
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. | |||
The Origin Set is unaffected by any alternative services [RFC7838] | ||||
advertisements made by the server. Advertising an alternative | ||||
service does not affect whether a server is authoritative. | ||||
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 6, line 25 ¶ | skipping to change at page 6, line 50 ¶ | |||
4. Security Considerations | 4. Security Considerations | |||
Clients that blindly trust the ORIGIN frame's contents will be | Clients that blindly trust the ORIGIN frame's contents will be | |||
vulnerable to a large number of attacks. See Section 2.4 for | vulnerable to a large number of attacks. See Section 2.4 for | |||
mitigations. | mitigations. | |||
Relaxing the requirement to consult DNS when determining authority | Relaxing the requirement to consult DNS when determining authority | |||
for an origin means that an attacker who possesses a valid | for an origin means that an attacker who possesses a valid | |||
certificate no longer needs to be on-path to redirect traffic to | certificate no longer needs to be on-path to redirect traffic to | |||
them; instead of modifying DNS, they need only convince the user to | them; instead of modifying DNS, they need only convince the user to | |||
visit another Web site, in order to coalesce connections to the | visit another Web site in order to coalesce connections to the target | |||
target onto their existing connection. | onto their existing connection. | |||
As a result, clients opting not to consult DNS ought to employ some | ||||
alternative means to increase confidence that the certificate is | ||||
legitimate. Examples of mechanisms that can give additional | ||||
confidence in a certificate include checking for a Signed Certificate | ||||
Timestamp [RFC6929] and performing certificate revocation checks. | ||||
Clients opting not to consult DNS ought to do so only if they have a | ||||
high degree of confidence that the certificate is legitimate. For | ||||
instance, clients might skip consulting DNS only if they receive | ||||
proof of inclusion in a Certificate Transparency log [RFC6929] or | ||||
they have a recent OCSP response [RFC6960] (possibly using the | ||||
"status_request" TLS extension [RFC6066]) showing that the | ||||
certificate was not revoked. | ||||
The Origin Set's size is unbounded by this specification, and thus | ||||
could be used by attackers to exhaust client resources. To mitigate | ||||
this risk, clients can monitor their state commitment and close the | ||||
connection if it is too high. | ||||
5. References | 5. References | |||
5.1. Normative References | 5.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, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc2119>. | editor.org/info/rfc2119>. | |||
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | |||
DOI 10.17487/RFC2818, May 2000, | DOI 10.17487/RFC2818, May 2000, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc2818>. | editor.org/info/rfc2818>. | |||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | |||
<http://www.rfc-editor.org/info/rfc5280>. | <https://www.rfc-editor.org/info/rfc5280>. | |||
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | |||
Extensions: Extension Definitions", RFC 6066, | Extensions: Extension Definitions", RFC 6066, | |||
DOI 10.17487/RFC6066, January 2011, | DOI 10.17487/RFC6066, January 2011, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc6066>. | editor.org/info/rfc6066>. | |||
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, | [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, | |||
DOI 10.17487/RFC6454, December 2011, | DOI 10.17487/RFC6454, December 2011, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc6454>. | editor.org/info/rfc6454>. | |||
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | |||
DOI 10.17487/RFC7540, May 2015, | DOI 10.17487/RFC7540, May 2015, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc7540>. | editor.org/info/rfc7540>. | |||
5.2. Informative References | 5.2. Informative References | |||
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, | [RFC5988] Nottingham, M., "Web Linking", RFC 5988, | |||
DOI 10.17487/RFC5988, October 2010, | DOI 10.17487/RFC5988, October 2010, <https://www.rfc- | |||
<http://www.rfc-editor.org/info/rfc5988>. | editor.org/info/rfc5988>. | |||
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User | ||||
Service (RADIUS) Protocol Extensions", RFC 6929, | ||||
DOI 10.17487/RFC6929, April 2013, <https://www.rfc- | ||||
editor.org/info/rfc6929>. | ||||
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., | ||||
Galperin, S., and C. Adams, "X.509 Internet Public Key | ||||
Infrastructure Online Certificate Status Protocol - OCSP", | ||||
RFC 6960, DOI 10.17487/RFC6960, June 2013, | ||||
<https://www.rfc-editor.org/info/rfc6960>. | ||||
[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>. | <https://www.rfc-editor.org/info/rfc7230>. | |||
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP | [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP | |||
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, | Alternative Services", RFC 7838, DOI 10.17487/RFC7838, | |||
April 2016, <http://www.rfc-editor.org/info/rfc7838>. | April 2016, <https://www.rfc-editor.org/info/rfc7838>. | |||
Appendix A. Non-Normative Processing Algorithm | Appendix A. Non-Normative Processing Algorithm | |||
The following algorithm illustrates how a client could handle | The following algorithm illustrates how a client could handle | |||
received ORIGIN frames: | received ORIGIN frames: | |||
1. If the client is configured to use a proxy for the connection, | 1. If the client is configured to use a proxy for the connection, | |||
ignore the frame and stop processing. | ignore the frame and stop processing. | |||
2. If the connection is not identified with the "h2" protocol | 2. If the connection is not identified with the "h2" protocol | |||
skipping to change at page 7, line 50 ¶ | skipping to change at page 9, line 8 ¶ | |||
3. If the frame occurs upon any stream except stream 0, ignore the | 3. If the frame occurs upon any stream except stream 0, ignore the | |||
frame and stop processing. | frame and stop processing. | |||
4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the | 4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the | |||
frame and stop processing. | frame and stop processing. | |||
5. If no previous ORIGIN frame on the connection has reached this | 5. If no previous ORIGIN frame on the connection has reached this | |||
step, initialise the Origin Set as per Section 2.3. | step, initialise the Origin Set as per Section 2.3. | |||
6. For each Origin field "origin_raw" in the frame payload: | 6. For each "Origin-Entry" in the frame payload: | |||
1. Parse "origin_raw" as an ASCII serialization of an origin | 1. Parse "ASCII-Origin" 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- | |||
"origin_raw". | Entry". | |||
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. 37 change blocks. | ||||
76 lines changed or deleted | 136 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/ |