idnits 2.17.1 draft-ietf-httpbis-origin-frame-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 28, 2016) is 2767 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group M. Nottingham 3 Internet-Draft E. Nygren 4 Intended status: Standards Track Akamai 5 Expires: April 1, 2017 September 28, 2016 7 The ORIGIN HTTP/2 Frame 8 draft-ietf-httpbis-origin-frame-01 10 Abstract 12 This document specifies the ORIGIN frame for HTTP/2, to indicate what 13 origins are available on a given connection. 15 Note to Readers 17 Discussion of this draft takes place on the HTTP working group 18 mailing list (ietf-http-wg@w3.org), which is archived at 19 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 21 Working Group information can be found at http://httpwg.github.io/ ; 22 source code and issues list for this draft can be found at 23 https://github.com/httpwg/http-extensions/labels/origin-frame . 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 1, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 61 2. The ORIGIN HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 2 62 2.1. The Origin Set . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Processing ORIGIN Frames . . . . . . . . . . . . . . . . 4 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 4. Normative References . . . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 HTTP/2 [RFC7540] allows clients to coalesce different origins 71 [RFC6454] onto the same connection when certain conditions are met. 72 However, in certain cases, a connection is is not usable for a 73 coalesced origin, so the 421 (Misdirected Request) status code 74 ([RFC7540], Section 9.1.2) was defined. 76 Using a status code in this manner allows clients to recover from 77 misdirected requests, but at the penalty of adding latency. To 78 address that, this specification defines a new HTTP/2 frame type, 79 "ORIGIN", to allow servers to indicate what origins a connection is 80 usable for. 82 1.1. Notational Conventions 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. The ORIGIN HTTP/2 Frame 90 The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to 91 indicate what origin(s) [RFC6454] the server would like the client to 92 consider as members of the Origin Set (Section 2.1) for the 93 connection it occurs within. 95 The ORIGIN frame type is 0xb (decimal 11). 97 +-------------------------------+-------------------------------+ 98 | Origin-Len (16) | Origin? (*) ... 99 +-------------------------------+-------------------------------+ 101 The ORIGIN frame's payload contains the following fields, sets of 102 which may be repeated within the frame to indicate multiple origins: 104 Origin-Len: An unsigned, 16-bit integer indicating the length, in 105 octets, of the Origin field. 107 Origin: An optional sequence of characters containing the ASCII 108 serialization of an origin ([RFC6454], Section 6.2) that the 109 sender believes this connection is or could be authoritative for. 111 The ORIGIN frame defines the following flags: 113 CLEAR (0x1): Indicates that the Origin Set MUST be reset to an empty 114 set before processing the contents of the frame it occurs upon. 116 REMOVE (0x2): Indicates that the origin(s) carried in the payload 117 must be removed from the Origin Set, if present; if not present, 118 it/they have no effect. 120 2.1. The Origin Set 122 The set of origins (as per [RFC6454]) that a given connection might 123 be used for is known in this specification as the Origin Set. 125 When a connection is first established, its Origin Set is defined to 126 be those origins that the client would normally consider the 127 connection authoritative for; see [RFC7540], Section 10.1. 129 The ORIGIN frame allows the server to modify the Origin Set. In 130 particular: 132 1. A server can add to its members by sending an ORIGIN frame 133 (without any flags set); 135 2. A server can prune one or more origins from it by sending an 136 ORIGIN frame with the REMOVE flag set; 138 3. A server can remove all its members and then add zero or more 139 members by sending an ORIGIN frame with the CLEAR flag set and a 140 payload containing the new origins. 142 Adding to the Origin Set (cases 1 and 3 above) does not imply that 143 the connection is authoritative for the added origins (in the sense 144 of [RFC7540], Section 10.1) on its own; this MUST be established by 145 some other mechanism. 147 A client that implements this specification MUST NOT use a connection 148 for a given origin unless that origin appears in the Origin Set for 149 the connection, regardless of whether or not it believes that the 150 connection is authoritative for that origin. 152 2.2. Processing ORIGIN Frames 154 The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints 155 that do not support this frame can safely ignore it upon receipt. 157 When received by a client, it can be used to inform HTTP/2 connection 158 coalescing (see Section 2.1), but does not relax the requirement 159 there that the server is authoritative. 161 The origin frame MUST be sent on stream 0; an ORIGIN frame on any 162 other stream is invalid and MUST be ignored. 164 The ORIGIN frame is processed hop-by-hop. An intermediary MUST NOT 165 forward ORIGIN frames. Clients configured to use a proxy MUST ignore 166 any ORIGIN frames received from it. 168 The following algorithm illustrates how a client can handle received 169 ORIGIN frames: 171 1. If the client is configured to use a proxy, ignore the frame and 172 stop processing. 174 2. If the frame occurs upon any stream except stream 0, ignore the 175 frame and stop processing. 177 3. If the CLEAR flag is set, remove all members from the Origin Set. 179 4. For each Origin field "origin_raw" in the frame payload: 181 1. Parse "origin_raw" as an ASCII serialization of an origin 182 ([RFC6454], Section 6.2) and let the result be 183 "parsed_origin". 185 2. If the REMOVE flag is set, remove any member of the Origin 186 Set that is the same as "parsed_origin" (as per [RFC6454], 187 Section 5), and continue to the next "parsed_origin". 189 3. Otherwise, add "parsed_origin" to the Origin Set. 191 3. Security Considerations 193 Clients that blindly trust the ORIGIN frame's contents will be 194 vulnerable to a large number of attacks; hence the reinforcement that 195 this specification does not relax the requirement for server 196 authority in [RFC7540], Section 10.1. 198 4. Normative References 200 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 201 Requirement Levels", BCP 14, RFC 2119, 202 DOI 10.17487/RFC2119, March 1997, 203 . 205 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 206 DOI 10.17487/RFC6454, December 2011, 207 . 209 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 210 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 211 DOI 10.17487/RFC7540, May 2015, 212 . 214 Authors' Addresses 216 Mark Nottingham 217 Akamai 219 Email: mnot@mnot.net 220 URI: https://www.mnot.net/ 222 Erik Nygren 223 Akamai 225 Email: nygren@akamai.com