idnits 2.17.00 (12 Aug 2021) /tmp/idnits16897/draft-ietf-httpbis-alt-svc-05.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 (December 1, 2014) is 2727 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) == Outdated reference: draft-ietf-httpbis-http2 has been published as RFC 7540 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTPbis Working Group M. Nottingham 3 Internet-Draft Akamai 4 Intended status: Standards Track P. McManus 5 Expires: June 4, 2015 Mozilla 6 J. Reschke 7 greenbytes 8 December 1, 2014 10 HTTP Alternative Services 11 draft-ietf-httpbis-alt-svc-05 13 Abstract 15 This document specifies "alternative services" for HTTP, which allow 16 an origin's resources to be authoritatively available at a separate 17 network location, possibly accessed with a different protocol 18 configuration. 20 Editorial Note (To be removed by RFC Editor) 22 Discussion of this draft takes place on the HTTPBIS working group 23 mailing list (ietf-http-wg@w3.org), which is archived at 24 . 26 Working Group information can be found at 27 and ; 28 source code and issues list for this draft can be found at 29 . 31 The changes in this draft are summarized in Appendix A. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on June 4, 2015. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4 69 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5 70 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 6 71 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7 72 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7 73 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 7 74 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 8 75 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 10 76 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 10 77 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 11 78 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 12 81 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 13 82 8. Internationalization Considerations . . . . . . . . . . . . . 13 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 13 85 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 14 86 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 14 87 9.4. Tracking Clients Using Alternative Services . . . . . . . 15 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 92 Appendix A. Change Log (to be removed by RFC Editor before 93 publication) . . . . . . . . . . . . . . . . . . . . 16 94 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 16 95 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 16 96 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 16 97 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 17 98 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 17 99 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 17 101 1. Introduction 103 HTTP [RFC7230] conflates the identification of resources with their 104 location. In other words, "http://" (and "https://") URLs are used 105 to both name and find things to interact with. 107 In some cases, it is desirable to separate identification and 108 location in HTTP; keeping the same identifier for a resource, but 109 interacting with it at a different location on the network. 111 For example: 113 o An origin server might wish to redirect a client to a different 114 server when it needs to go down for maintenance, or it has found a 115 server in a location that is more local to the client. 117 o An origin server might wish to offer access to its resources using 118 a new protocol (such as HTTP/2, see [HTTP2]) or one using improved 119 security (such as Transport Layer Security (TLS), see [RFC5246]). 121 o An origin server might wish to segment its clients into groups of 122 capabilities, such as those supporting Server Name Indication 123 (SNI, see Section 3 of [RFC6066]) and those not supporting it, for 124 operational purposes. 126 This specification defines a new concept in HTTP, "Alternative 127 Services", that allows an origin server to nominate additional means 128 of interacting with it on the network. It defines a general 129 framework for this in Section 2, along with specific mechanisms for 130 advertising their existence using HTTP header fields (Section 3) or 131 an HTTP/2 frame type (Section 4). 133 It also introduces a new status code in Section 6, so that origin 134 servers (or their nominated alternatives) can indicate that they are 135 not authoritative for a given origin, in cases where the wrong 136 location is used. 138 1.1. Notational Conventions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 This document uses the Augmented BNF defined in [RFC5234] along with 145 the "OWS", "delta-seconds", "parameter", "port", "quoted-string", 146 "token", and "uri-host" rules from [RFC7230], and uses the "#rule" 147 extension defined in Section 7 of that document. 149 2. Alternative Services Concepts 151 This specification defines a new concept in HTTP, the "alternative 152 service". When an origin (see [RFC6454]) has resources that are 153 accessible through a different protocol / host / port combination, it 154 is said to have an alternative service available. 156 An alternative service can be used to interact with the resources on 157 an origin server at a separate location on the network, possibly 158 using a different protocol configuration. Alternative services are 159 considered authoritative for an origin's resources, in the sense of 160 [RFC7230], Section 9.1. 162 For example, an origin: 164 ("http", "www.example.com", "80") 166 might declare that its resources are also accessible at the 167 alternative service: 169 ("h2", "new.example.com", "81") 171 By their nature, alternative services are explicitly at the 172 granularity of an origin; i.e., they cannot be selectively applied to 173 resources within an origin. 175 Alternative services do not replace or change the origin for any 176 given resource; in general, they are not visible to the software 177 "above" the access mechanism. The alternative service is essentially 178 alternative routing information that can also be used to reach the 179 origin in the same way that DNS CNAME or SRV records define routing 180 information at the name resolution level. Each origin maps to a set 181 of these routes -- the default route is derived from origin itself 182 and the other routes are introduced based on alternative-protocol 183 information. 185 Furthermore, it is important to note that the first member of an 186 alternative service tuple is different from the "scheme" component of 187 an origin; it is more specific, identifying not only the major 188 version of the protocol being used, but potentially communication 189 options for that protocol. 191 This means that clients using an alternative service can change the 192 host, port and protocol that they are using to fetch resources, but 193 these changes MUST NOT be propagated to the application that is using 194 HTTP; from that standpoint, the URI being accessed and all 195 information derived from it (scheme, host, port) are the same as 196 before. 198 Importantly, this includes its security context; in particular, when 199 TLS [RFC5246] is in use, the alternative service will need to present 200 a certificate for the origin's host name, not that of the 201 alternative. Likewise, the Host header field ([RFC7230], Section 202 5.4) is still derived from the origin, not the alternative service 203 (just as it would if a CNAME were being used). 205 The changes MAY, however, be made visible in debugging tools, 206 consoles, etc. 208 Formally, an alternative service is identified by the combination of: 210 o An Application Layer Protocol Negotiation (ALPN) protocol, as per 211 [RFC7301] 213 o A host, as per [RFC3986], Section 3.2.2 215 o A port, as per [RFC3986], Section 3.2.3 217 Additionally, each alternative service MUST have: 219 o A freshness lifetime, expressed in seconds; see Section 2.2 221 There are many ways that a client could discover the alternative 222 service(s) associated with an origin. This document describes two 223 such mechanisms: an HTTP header field (Section 3) and an HTTP/2 frame 224 type (Section 4). 226 The remainder of this section describes requirements that are common 227 to alternative services, regardless of how they are discovered. 229 2.1. Host Authentication 231 Clients MUST NOT use alternative services with a host that is 232 different than the origin's without strong server authentication; 233 this mitigates the attack described in Section 9.2. One way to 234 achieve this is for the alternative to use TLS with a certificate 235 that is valid for that origin. 237 For example, if the origin's host is "www.example.com" and an 238 alternative is offered on "other.example.com" with the "h2" protocol, 239 and the certificate offered is valid for "www.example.com", the 240 client can use the alternative. However, if "other.example.com" is 241 offered with the "h2c" protocol, the client cannot use it, because 242 there is no mechanism in that protocol to establish strong server 243 authentication. 245 2.2. Alternative Service Caching 247 Mechanisms for discovering alternative services also associate a 248 freshness lifetime with them; for example, the Alt-Svc header field 249 uses the "ma" parameter. 251 Clients MAY choose to use an alternative service instead of the 252 origin at any time when it is considered fresh; see Section 2.4 for 253 specific recommendations. 255 Clients with existing connections to an alternative service do not 256 need to stop using it when its freshness lifetime ends; i.e., the 257 caching mechanism is intended for limiting how long an alternative 258 service can be used for establishing new requests, not limiting the 259 use of existing ones. 261 Clients ought to consider that changes in network configurations can 262 result in suboptimal or compromised cached alternative services. 264 2.3. Requiring Server Name Indication 266 A client MUST only use a TLS-based alternative service if the client 267 also supports TLS Server Name Indication (SNI). This supports the 268 conservation of IP addresses on the alternative service host. 270 Note that the SNI information provided in TLS by the client will be 271 that of the origin, not the alternative (as will the Host HTTP header 272 field-value). 274 2.4. Using Alternative Services 276 By their nature, alternative services are OPTIONAL: clients do not 277 need to use them. However, it is advantageous for clients to behave 278 in a predictable way when they are used by servers (e.g., for load 279 balancing). 281 Therefore, if a client becomes aware of an alternative service, the 282 client SHOULD use that alternative service for all requests to the 283 associated origin as soon as it is available, provided that the 284 security properties of the alternative service protocol are 285 desirable, as compared to the existing connection. 287 If a client becomes aware of multiple alternative services, it MAY 288 choose the most suitable according to its own criteria (again, 289 keeping security properties in mind). For example, an origin might 290 advertise multiple alternative services to notify clients of support 291 for multiple versions of HTTP; or, an alternative service might 292 itself advertise an alternative. 294 When a client uses an alternate service, it MUST emit the Alt-Used 295 header field (Section 5) on every request using that alternate 296 service. 298 The client does not need to block requests on any existing 299 connection; it can be used until the alternative connection is 300 established. However, if the security properties of the existing 301 connection are weak (e.g. cleartext HTTP/1.1) then it might make 302 sense to block until the new connection is fully available in order 303 to avoid information leakage. 305 Furthermore, if the connection to the alternative service fails or is 306 unresponsive, the client MAY fall back to using the origin or another 307 alternative service. Note, however, that this could be the basis of 308 a downgrade attack, thus losing any enhanced security properties of 309 the alternative service. 311 3. The Alt-Svc HTTP Header Field 313 An HTTP(S) origin server can advertise the availability of 314 alternative services to clients by adding an Alt-Svc header field to 315 responses. 317 Alt-Svc = 1#( alternative *( OWS ";" OWS parameter ) ) 318 alternative = protocol-id "=" alt-authority 319 protocol-id = token ; percent-encoded ALPN protocol identifier 320 alt-authority = quoted-string ; containing [ uri-host ] ":" port 322 ALPN protocol names are octet sequences with no additional 323 constraints on format. Octets not allowed in tokens ([RFC7230], 324 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of 325 [RFC3986]. Consequently, the octet representing the percent 326 character "%" (hex 25) MUST be percent-encoded as well. 328 In order to have precisely one way to represent any ALPN protocol 329 name, the following additional constraints apply: 331 1. Octets in the ALPN protocol MUST NOT be percent-encoded if they 332 are valid token characters except "%", and 334 2. When using percent-encoding, uppercase hex digits MUST be used. 336 With these constraints, recipients can apply simple string comparison 337 to match protocol identifiers. 339 The "alt-authority" component consists of an OPTIONAL uri-host 340 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port 341 number. 343 For example: 345 Alt-Svc: h2=":8000" 347 This indicates the "h2" protocol ([HTTP2]) on the same host using the 348 indicated port 8000. 350 An example involving a change of host: 352 Alt-Svc: h2="new.example.org:80" 354 This indicates the "h2" protocol on the host "new.example.org", 355 running on port 80. Note that the "quoted-string" syntax needs to be 356 used because ":" is not an allowed character in "token". 358 Examples for protocol name escaping: 360 +--------------------+-------------+---------------------+ 361 | ALPN protocol name | protocol-id | Note | 362 +--------------------+-------------+---------------------+ 363 | h2 | h2 | No escaping needed | 364 +--------------------+-------------+---------------------+ 365 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped | 366 +--------------------+-------------+---------------------+ 367 | x%y | x%25y | "%" needs escaping | 368 +--------------------+-------------+---------------------+ 370 Alt-Svc MAY occur in any HTTP response message, regardless of the 371 status code. 373 The Alt-Svc field value can have multiple values: 375 Alt-Svc: h2c=":8000", h2=":443" 377 The value(s) advertised by Alt-Svc can be used by clients to open a 378 new connection to one or more alternative services immediately, or 379 simultaneously with subsequent requests on the same connection. 381 When using HTTP/2 ([HTTP2]), servers SHOULD instead send an ALTSVC 382 frame (Section 4). A single ALTSVC frame can be sent for a 383 connection; a new frame is not needed for every request. 385 Note that all field elements that allow "quoted-string" syntax MUST 386 be processed as per Section 3.2.6 of [RFC7230]. 388 3.1. Caching Alt-Svc Header Field Values 390 When an alternative service is advertised using Alt-Svc, it is 391 considered fresh for 24 hours from generation of the message. This 392 can be modified with the 'ma' (max-age) parameter; 394 Alt-Svc: h2=":443"; ma=3600 396 which indicates the number of seconds since the response was 397 generated the alternative service is considered fresh for. 399 ma = delta-seconds 401 See Section 4.2.3 of [RFC7234] for details of determining response 402 age. 404 For example, a response: 406 HTTP/1.1 200 OK 407 Content-Type: text/html 408 Cache-Control: 600 409 Age: 30 410 Alt-Svc: h2c=":8000"; ma=60 412 indicates that an alternative service is available and usable for the 413 next 60 seconds. However, the response has already been cached for 414 30 seconds (as per the Age header field value), so therefore the 415 alternative service is only fresh for the 30 seconds from when this 416 response was received, minus estimated transit time. 418 Note that the freshness lifetime for HTTP caching (here, 600 seconds) 419 does not affect caching of Alt-Svc values. 421 When an Alt-Svc response header field is received from an origin, its 422 value invalidates and replaces all cached alternative services for 423 that origin. 425 See Section 2.2 for general requirements on caching alternative 426 services. 428 4. The ALTSVC HTTP/2 Frame 430 The ALTSVC HTTP/2 frame ([HTTP2], Section 4) advertises the 431 availability of an alternative service to an HTTP/2 client. 433 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints 434 that do not support this frame can safely ignore it. 436 An ALTSVC frame from a server to a client on a client-initiated 437 stream indicates that the conveyed alternative service is associated 438 with the origin of that stream. 440 An ALTSVC frame from a server to a client on stream 0 indicates that 441 the conveyed alternative service is associated with the origin 442 contained in the Origin field of the frame. An association with an 443 origin that the client does not consider authoritative for the 444 current connection MUST be ignored. 446 The ALTSVC frame type is 0xa (decimal 10). 448 The payload of an ALTSVC frame is identical to the payload of the 449 Alt-Svc field value defined in Section 3 (ABNF production "Alt-Svc"). 451 The ALTSVC frame does not define any flags. 453 The ALTSVC frame is intended for receipt by clients; a server that 454 receives an ALTSVC frame MUST treat it as a connection error of type 455 PROTOCOL_ERROR. 457 An ALTSVC frame on a client-initiated stream containing non-empty 458 "Origin" information is invalid and MUST be ignored. Likewise, an 459 ALTSVC frame on stream 0 with empty (length 0) "Origin" information 460 is invalid and MUST be ignored. 462 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT 463 forward ALTSVC frames, though it can use the information contained in 464 ALTSVC frames in forming new ALTSVC frames to send to its own 465 clients. 467 5. The Alt-Used HTTP Header Field 469 The Alt-Used header field is used in requests to indicate that an 470 alternate service is in use. 472 Alt-Used = use-flag *( OWS ";" OWS ext-param ) 473 use-flag = "1" / "0" 474 ext-param = token "=" ( token / quoted-string ) 476 Alt-Used is intended to allow alternate services to avoid sending 477 alternative service indications where there is a risk of generating a 478 loops. It also allows a service to identify requests for accounting 479 and load balancing purposes. 481 When using an alternative service, clients MUST include a Alt-Used 482 header field in all requests. 484 A flag value of "1" indicates that an alternate service was used, 485 while "0" means it was not. 487 For example: 489 GET /thing HTTP/1.1 490 Host: origin.example.com 491 Alt-Used: 1 493 The extension parameters (ext-param) are reserved for future use; 494 specifications that want to define an extension will need to update 495 this document (and ought to introduce an extension registry). 497 6. The 421 Misdirected Request HTTP Status Code 499 The 421 (Misdirected Request) status code is defined in Section 9.1.2 500 of [HTTP2] to indicate that the current server instance is not 501 authoritative for the requested resource. This can be used to 502 indicate that an alternative service is not authoritative; see 503 Section 2). 505 Clients receiving 421 (Misdirected Request) from an alternative 506 service MUST remove the corresponding entry from its alternative 507 service cache (see Section 2.2) for that origin. Regardless of the 508 idempotency of the request method, they MAY retry the request, either 509 at another alternative server, or at the origin. 511 A 421 (Misdirected Request) response MAY carry an Alt-Svc header 512 field. 514 7. IANA Considerations 516 7.1. Header Field Registrations 518 HTTP header fields are registered within the "Message Headers" 519 registry maintained at 520 . 522 This document defines the following HTTP header fields, so their 523 associated registry entries shall be added according to the permanent 524 registrations below (see [BCP90]): 526 +-------------------+----------+----------+-----------+ 527 | Header Field Name | Protocol | Status | Reference | 528 +-------------------+----------+----------+-----------+ 529 | Alt-Svc | http | standard | Section 3 | 530 | Alt-Used | http | standard | Section 5 | 531 +-------------------+----------+----------+-----------+ 533 The change controller is: "IETF (iesg@ietf.org) - Internet 534 Engineering Task Force". 536 7.2. The ALTSVC HTTP/2 Frame Type 538 This document registers the ALTSVC frame type in the HTTP/2 Frame 539 Types registry ([HTTP2], Section 11.2). 541 Frame Type: ALTSVC 543 Code: 0xa 545 Specification: Section 4 of this document 547 8. Internationalization Considerations 549 An internationalized domain name that appears in either the header 550 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed 551 using A-labels ([RFC5890], Section 2.3.2.1). 553 9. Security Considerations 555 9.1. Changing Ports 557 Using an alternative service implies accessing an origin's resources 558 on an alternative port, at a minimum. An attacker that can inject 559 alternative services and listen at the advertised port is therefore 560 able to hijack an origin. 562 For example, an attacker that can add HTTP response header fields can 563 redirect traffic to a different port on the same host using the Alt- 564 Svc header field; if that port is under the attacker's control, they 565 can thus masquerade as the HTTP server. 567 This risk can be mitigated by restricting the ability to advertise 568 alternative services, and restricting who can open a port for 569 listening on that host. 571 9.2. Changing Hosts 573 When the host is changed due to the use of an alternative service, it 574 presents an opportunity for attackers to hijack communication to an 575 origin. 577 For example, if an attacker can convince a user agent to send all 578 traffic for "innocent.example.org" to "evil.example.com" by 579 successfully associating it as an alternative service, they can 580 masquerade as that origin. This can be done locally (see mitigations 581 in Section 9.1) or remotely (e.g., by an intermediary as a man-in- 582 the-middle attack). 584 This is the reason for the requirement in Section 2.1 that any 585 alternative service with a host different to the origin's be strongly 586 authenticated with the origin's identity; i.e., presenting a 587 certificate for the origin proves that the alternative service is 588 authorized to serve traffic for the origin. 590 However, this authorization is only as strong as the method used to 591 authenticate the alternative service. In particular, there are well- 592 known exploits to make an attacker's certificate appear as 593 legitimate. 595 Alternative services could be used to persist such an attack; for 596 example, an intermediary could man-in-the-middle TLS-protected 597 communication to a target, and then direct all traffic to an 598 alternative service with a large freshness lifetime, so that the user 599 agent still directs traffic to the attacker even when not using the 600 intermediary. 602 9.3. Changing Protocols 604 When the ALPN protocol is changed due to the use of an alternative 605 service, the security properties of the new connection to the origin 606 can be different from that of the "normal" connection to the origin, 607 because the protocol identifier itself implies this. 609 For example, if a "https://" URI had a protocol advertised that does 610 not use some form of end-to-end encryption (most likely, TLS), it 611 violates the expectations for security that the URI scheme implies. 613 Therefore, clients cannot blindly use alternative services, but 614 instead evaluate the option(s) presented to assure that security 615 requirements and expectations (of specifications, implementations and 616 end users) are met. 618 9.4. Tracking Clients Using Alternative Services 620 Choosing an alternative service implies connecting to a new, server- 621 supplied host name. By using many different (potentially unique) 622 host names, servers could conceivably track client requests. 624 Clients concerned by the additional fingerprinting can choose to 625 ignore alternative service advertisements. 627 In a browser, any alternative service information MUST be removed 628 when origin-specific data is cleared (for instance, when cookies are 629 cleared). 631 10. Acknowledgements 633 Thanks to Adam Langley, Eliot Lear, Erik Nygren, Guy Podjarny, Paul 634 Hoffman, Richard Barnes, Stephen Farrell, Stephen Ludin, and Will 635 Chan for their feedback and suggestions. 637 The Alt-Svc header field was influenced by the design of the 638 Alternate-Protocol header field in SPDY. 640 11. References 642 11.1. Normative References 644 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 645 Transfer Protocol version 2", draft-ietf-httpbis-http2-16 646 (work in progress), November 2014. 648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 649 Requirement Levels", BCP 14, RFC 2119, March 1997. 651 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 652 Resource Identifier (URI): Generic Syntax", STD 66, 653 RFC 3986, January 2005. 655 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 656 Specifications: ABNF", STD 68, RFC 5234, January 2008. 658 [RFC5890] Klensin, J., "Internationalized Domain Names for 659 Applications (IDNA): Definitions and Document Framework", 660 RFC 5890, August 2010. 662 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 663 Extension Definitions", RFC 6066, January 2011. 665 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 666 December 2011. 668 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 669 Protocol (HTTP/1.1): Message Syntax and Routing", 670 RFC 7230, June 2014. 672 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 673 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 674 RFC 7234, June 2014. 676 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, 677 "Transport Layer Security (TLS) Application-Layer Protocol 678 Negotiation Extension", RFC 7301, July 2014. 680 11.2. Informative References 682 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 683 Procedures for Message Header Fields", BCP 90, RFC 3864, 684 September 2004. 686 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 687 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 689 Appendix A. Change Log (to be removed by RFC Editor before publication) 691 A.1. Since draft-nottingham-httpbis-alt-svc-05 693 This is the first version after adoption of 694 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It 695 only contains editorial changes. 697 A.2. Since draft-ietf-httpbis-alt-svc-00 699 Selected 421 as proposed status code for "Not Authoritative". 701 Changed header field syntax to use percent-encoding of ALPN protocol 702 names (). 704 A.3. Since draft-ietf-httpbis-alt-svc-01 706 Updated HTTP/1.1 references. 708 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag 709 to address fingerprinting concerns 710 (). 712 Note that ALTSVC frame is preferred to Alt-Svc header field 713 (). 715 Incorporate ALTSRV frame 716 (). 718 Moved definition of status code 421 to HTTP/2. 720 Partly resolved . 722 A.4. Since draft-ietf-httpbis-alt-svc-02 724 Updated ALPN reference. 726 Resolved . 728 A.5. Since draft-ietf-httpbis-alt-svc-03 730 Renamed "Alt-Svc-Used" to "Alt-Used" 731 (). 733 Clarify ALTSVC Origin information requirements 734 (). 736 Remove/tune language with respect to tracking risks (see 737 ). 739 A.6. Since draft-ietf-httpbis-alt-svc-04 741 Mention tracking by alt-svc host name in Security Considerations 742 (). 744 "421 (Not Authoritative)" -> "421 (Misdirected Request)". 746 Allow the frame to carry multiple indicator and use the same payload 747 formats for both 748 (). 750 Authors' Addresses 752 Mark Nottingham 753 Akamai 755 EMail: mnot@mnot.net 756 URI: https://www.mnot.net/ 757 Patrick McManus 758 Mozilla 760 EMail: mcmanus@ducksong.com 761 URI: https://mozillians.org/u/pmcmanus/ 763 Julian F. Reschke 764 greenbytes GmbH 766 EMail: julian.reschke@greenbytes.de 767 URI: https://greenbytes.de/tech/webdav/