idnits 2.17.1 draft-nottingham-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 (January 31, 2016) is 3005 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 Network Working Group M. Nottingham 3 Internet-Draft E. Nygren 4 Intended status: Standards Track Akamai 5 Expires: August 3, 2016 January 31, 2016 7 The ORIGIN HTTP/2 Frame 8 draft-nottingham-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 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 3, 2016. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 2 51 1.2. The ORIGIN HTTP/2 Frame . . . . . . . . . . . . . . . . . 2 52 2. Security Considerations . . . . . . . . . . . . . . . . . . . 3 53 3. Normative References . . . . . . . . . . . . . . . . . . . . 3 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 56 1. Introduction 58 HTTP/2 [RFC7540] allows clients to coalesce different origins 59 [RFC6454] onto the same connection when certain conditions are met. 60 In some cases, the server is not authoritative for a coalesced 61 origin, so the 421 (Misdirected Request) status code was defined. 63 Using a status code in this manner allows clients to recover from 64 misdirected requests, but at the penalty of adding latency. To 65 address that, this specification defines a new HTTP/2 frame type, 66 "ORIGIN", to allow servers to indicate what origins a connection is 67 authoritative for. 69 1.1. Notational Conventions 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 1.2. The ORIGIN HTTP/2 Frame 77 The ORIGIN HTTP/2 frame ([RFC7540], Section 4) indicates what 78 origin(s) [RFC6454] the sender considers this connection 79 authoritative for (in the sense of [RFC7540], Section 10.1). 81 The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints 82 that do not support this frame can safely ignore it. 84 It MUST occur on stream 0; an ORIGIN frame on any other stream is 85 invalid and MUST be ignored. 87 When received by a client, it can be used to inform HTTP/2 connection 88 coalescing (see [RFC7540], Section 9.1.1), but does not relax the 89 requirement there that the server is authoritative. 91 If multiple ORIGIN frames are received on the same connection, only 92 the most recent is to be considered current. 94 Once an ORIGIN frame has been received and processed, clients that 95 implement this specification SHOULD NOT use that connection for a 96 given origin if it did not appear within the current ORIGIN frame. 98 The ORIGIN frame type is 0xb (decimal 11). 100 +-------------------------------+-------------------------------+ 101 | Origin-Len (16) | Origin? (*) ... 102 +-------------------------------+-------------------------------+ 104 The ORIGIN frame contains the following fields, sets of which may be 105 repeated within the frame to indicate multiple origins: 107 Origin-Len: An unsigned, 16-bit integer indicating the length, in 108 octets, of the Origin field. Origin: An optional sequence of 109 characters containing the ASCII serialization of an origin 110 ([RFC6454], Section 6.2) that the sender believes this connection is 111 authoritative for. 113 The ORIGIN frame does not define any flags. It can contain one or 114 more Origin-Len/Origin pairs. 116 The ORIGIN frame is processed hop-by-hop. An intermediary must not 117 forward ORIGIN frames. 119 Clients configured to use a proxy MUST ignore any ORIGIN frames 120 received from it. 122 2. Security Considerations 124 Clients that blindly trust the ORIGIN frame's contents will be 125 vulnerable to a large number of attacks; hence the reinforcement that 126 this specification does not relax the requirement for server 127 authority in [RFC7540], Section 10.1. 129 3. Normative References 131 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 132 Requirement Levels", BCP 14, RFC 2119, 133 DOI 10.17487/RFC2119, March 1997, 134 . 136 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 137 DOI 10.17487/RFC6454, December 2011, 138 . 140 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 141 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 142 DOI 10.17487/RFC7540, May 2015, 143 . 145 Authors' Addresses 147 Mark Nottingham 148 Akamai 150 Email: mnot@mnot.net 151 URI: http://www.mnot.net/ 153 Erik Nygren 154 Akamai 156 Email: nygren@akamai.com