idnits 2.17.1 draft-pardue-alt-svc-ext-unsupported-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 July 2020) is 1376 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 (ref. 'HTTP2') (Obsoleted by RFC 9113) == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-29 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP L. Pardue 3 Internet-Draft Cloudflare 4 Intended status: Standards Track 13 July 2020 5 Expires: 14 January 2021 7 HTTP Alternative Services That Do Not Support Desired Extensions 8 draft-pardue-alt-svc-ext-unsupported-00 10 Abstract 12 This document describes an error case when an HTTP Alternative 13 Service does not support the extension points of the original 14 connection. It defines an error code that can be used by endpoints 15 to signal the encounter. 17 Discussion Venues 19 This note is to be removed before publishing as an RFC. 21 Discussion of this document takes place on the ALT Working Group 22 mailing list (alt@ietf.org), which is archived at 23 https://mailarchive.ietf.org/arch/browse/alt/ 24 (https://mailarchive.ietf.org/arch/browse/alt/). 26 Source for this draft and an issue tracker can be found at 27 https://github.com/LPardue/draft-pardue-alt-svc-ext-unsupported 28 (https://github.com/LPardue/draft-pardue-alt-svc-ext-unsupported). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 14 January 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 65 3. Detecting and Signalling . . . . . . . . . . . . . . . . . . 3 66 4. HTTP/2 Error Code . . . . . . . . . . . . . . . . . . . . . . 4 67 5. HTTP/3 Error Code . . . . . . . . . . . . . . . . . . . . . . 4 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 4 72 8.2. Informative References . . . . . . . . . . . . . . . . . 5 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 76 1. Introduction 78 HTTP/2 ([HTTP2]) and HTTP/3 ([HTTP3]) provide several extension 79 points, only some of which require negotiation before use. For any 80 HTTP connection that is actively using extensions, it is possible 81 that the server might advertise an Alternative Service ([ALT-SVC]) 82 that contains no indication of whether the current extension points 83 are supported by indicated server. A client has to proactively 84 engage with the Alternative in order to determine what extension 85 points it supports, which will often require the client to establish 86 a new transport-layer connection and HTTP handshake. The client 87 might determine that the Alternative does not support the same 88 extensions as the current connection and decide to close the 89 connection. For an extension that is negotiated via SETTINGS frames, 90 the client might be able to detect the lack of extensions early in 91 the lifecycle. For other forms of extension, the problem might not 92 be detectable until later on, for instance when extension frame 93 exchanges fail. 95 The guidance in [ALT-SVC] has lead to clients that are robust to 96 different types of failures. Following a "make-before-break" 97 approach avoids active transfers being interupted by an opportunistic 98 change in connection. As such, testing an Alternative and finding 99 that its extension points are incompatible is unlikely to be a hard 100 failure cases. However, Alt-Svc is the primary method of switching 101 between HTTP/2 and HTTP/3 and there is a possibility that extensions 102 offered in one version of a connection are not provided in another. 103 It is also feasible that support for extension points are not 104 unilaterally deployed across a fleet of servers, whether in the same 105 organization domain or not. A client might encounter problems with 106 the Alternative due to permanent error or transient erro due to 107 synchronization or coordination issues between the origin and the 108 Alternative. 110 Advertising Alternative Services has quite a low barrier and does 111 require up front coordination, meaning it is quite easy for an origin 112 administrator to configure things that are logically invalid. 113 Alternatives can detect problems and take action; [ALT-SVC] defines 114 status 421 Misdirected Request that allows the Alternative to signal 115 such a problem. However, there is are cases where clients will be 116 misdirected to Alternatives that cannot satisfy the extension 117 expectations of the client. A server that detects this issue can 118 either close the connection or degrade into a mode that does not use 119 the extension. 121 This document defines an error code for HTTP/2 and HTTP/3 that can be 122 sent by an endpoint when closing streams or connections due to a 123 failure with extenstion expectations. This clearly disambiguates the 124 failure case from other types, i.e. general protocol error, which can 125 allow the peer to take more specific meaures, such as identifying 126 configuration errors. 128 2. Conventions and Definitions 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in 133 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Detecting and Signalling 138 HTTP/2 and HTTP/3 endpoints might use various means to detect that a 139 desired extension is not supported on the connection, no specific 140 measures are prescribed by this document. 142 When an endpoint detects that a desired extension is unsupported it 143 MAY terminate a stream or a connection with the error code 144 EXTENSION_UNSUPPORTED or H3_EXTENSION_UNSUPPORTED. 146 4. HTTP/2 Error Code 148 EXTENSION_UNSUPPORTED (0xf10): The endpoint detected that its peer 149 wants to use an extension that is not locally supported, or the peer 150 does not support an extension that is desired. 152 5. HTTP/3 Error Code 154 H3_EXTENSION_UNSUPPORTED (0x1f10): The endpoint detected that its 155 peer wants to use an extension that is not locally supported, or the 156 peer does not support an extension that is desired. 158 6. Security Considerations 160 None, probably. 162 7. IANA Considerations 164 This specification registers the following entry in the HTTP/2 Error 165 Code registry established by [HTTP2]: 167 Name: EXTENSION_UNSUPPORTED 169 Code: 0xf10 171 Description: Extension unsupported 173 Specification: This document 175 This specification registers the following entry in the HTTP/3 Error 176 Code registry established by [HTTP3]: 178 Name: EXTENSION_UNSUPPORTED 180 Code: 0x1f10 182 Description: Extension unsupported 184 Specification: This document 186 8. References 188 8.1. Normative References 190 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 191 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 192 DOI 10.17487/RFC7540, May 2015, 193 . 195 [HTTP3] Bishop, M., "Hypertext Transfer Protocol Version 3 196 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 197 quic-http-29, 9 June 2020, . 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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 206 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 207 May 2017, . 209 8.2. Informative References 211 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 212 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 213 April 2016, . 215 Acknowledgments 217 Patrick McManus, Mike Bishop and Ryan Hamilton shared some opinions 218 on the error cases of Alt-Svc, in various channels, that have been 219 incorporated into this document. 221 Author's Address 223 Lucas Pardue 224 Cloudflare 226 Email: lucaspardue.24.7@gmail.com