idnits 2.17.1
draft-ietf-httpbis-alt-svc-14.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 (March 8, 2016) is 2969 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 2818 (Obsoleted by RFC 9110)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112)
** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111)
** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 HTTP Working Group M. Nottingham
3 Internet-Draft Akamai
4 Intended status: Standards Track P. McManus
5 Expires: September 9, 2016 Mozilla
6 J. Reschke
7 greenbytes
8 March 8, 2016
10 HTTP Alternative Services
11 draft-ietf-httpbis-alt-svc-14
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 source code and issues list for this draft can be found at
28 .
30 The changes in this draft are summarized in Appendix A.
32 Status of This Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at http://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on September 9, 2016.
49 Copyright Notice
51 Copyright (c) 2016 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (http://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
67 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
68 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 5
69 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 7
70 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7
71 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 8
72 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8
73 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 9
74 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11
75 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12
76 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 14
77 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14
78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
79 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 15
80 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15
81 7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15
82 7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
83 7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 16
84 8. Internationalization Considerations . . . . . . . . . . . . . 16
85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
86 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16
87 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 17
88 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17
89 9.4. Tracking Clients Using Alternative Services . . . . . . . 18
90 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18
91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
93 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
94 Appendix A. Change Log (to be removed by RFC Editor before
95 publication) . . . . . . . . . . . . . . . . . . . . 20
96 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20
97 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 21
98 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 21
99 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21
100 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21
101 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21
102 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 22
103 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22
104 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22
105 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23
106 A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 24
107 A.12. Since draft-ietf-httpbis-alt-svc-10 . . . . . . . . . . . 24
108 A.13. Since draft-ietf-httpbis-alt-svc-11 . . . . . . . . . . . 24
109 A.14. Since draft-ietf-httpbis-alt-svc-12 . . . . . . . . . . . 24
110 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
112 1. Introduction
114 HTTP [RFC7230] conflates the identification of resources with their
115 location. In other words, "http://" and "https://" URIs are used to
116 both name and find things to interact with.
118 In some cases, it is desirable to separate identification and
119 location in HTTP; keeping the same identifier for a resource, but
120 interacting with it at a different location on the network.
122 For example:
124 o An origin server might wish to redirect a client to a different
125 server when it is under load, or it has found a server in a
126 location that is more local to the client.
128 o An origin server might wish to offer access to its resources using
129 a new protocol, such as HTTP/2 [RFC7540], or one using improved
130 security, such as Transport Layer Security (TLS) [RFC5246].
132 o An origin server might wish to segment its clients into groups of
133 capabilities, such as those supporting Server Name Indication
134 (SNI) (Section 3 of [RFC6066]), for operational purposes.
136 This specification defines a new concept in HTTP, "Alternative
137 Services", that allows an origin server to nominate additional means
138 of interacting with it on the network. It defines a general
139 framework for this in Section 2, along with specific mechanisms for
140 advertising their existence using HTTP header fields (Section 3) or
141 HTTP/2 frames (Section 4), plus a way to indicate that an alternative
142 service was used (Section 5).
144 It also endorses the status code 421 (Misdirected Request)
145 (Section 6) that origin servers or their nominated alternatives can
146 use to indicate that they are not authoritative for a given origin,
147 in cases where the wrong location is used.
149 1.1. Notational Conventions
151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
153 document are to be interpreted as described in [RFC2119].
155 This document uses the Augmented BNF defined in [RFC5234] and updated
156 by [RFC7405] along with the "#rule" extension defined in Section 7 of
157 [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and
158 [RFC7234]:
160 OWS =
161 delta-seconds =
162 port =
163 quoted-string =
164 token =
165 uri-host =
167 2. Alternative Services Concepts
169 This specification defines a new concept in HTTP, the "Alternative
170 Service". When an origin [RFC6454] has resources that are accessible
171 through a different protocol / host / port combination, it is said to
172 have an alternative service available.
174 An alternative service can be used to interact with the resources on
175 an origin server at a separate location on the network, possibly
176 using a different protocol configuration. Alternative services are
177 considered authoritative for an origin's resources, in the sense of
178 [RFC7230], Section 9.1.
180 For example, an origin:
182 ("http", "www.example.com", "80")
184 might declare that its resources are also accessible at the
185 alternative service:
187 ("h2", "new.example.com", "81")
189 By their nature, alternative services are explicitly at the
190 granularity of an origin; they cannot be selectively applied to
191 resources within an origin.
193 Alternative services do not replace or change the origin for any
194 given resource; in general, they are not visible to the software
195 "above" the access mechanism. The alternative service is essentially
196 alternative routing information that can also be used to reach the
197 origin in the same way that DNS CNAME or SRV records define routing
198 information at the name resolution level. Each origin maps to a set
199 of these routes -- the default route is derived from the origin
200 itself and the other routes are introduced based on alternative-
201 service information.
203 Furthermore, it is important to note that the first member of an
204 alternative service tuple is different from the "scheme" component of
205 an origin; it is more specific, identifying not only the major
206 version of the protocol being used, but potentially communication
207 options for that protocol.
209 This means that clients using an alternative service can change the
210 host, port and protocol that they are using to fetch resources, but
211 these changes MUST NOT be propagated to the application that is using
212 HTTP; from that standpoint, the URI being accessed and all
213 information derived from it (scheme, host, port) are the same as
214 before.
216 Importantly, this includes its security context; in particular, when
217 TLS [RFC5246] is used to authenticate, the alternative service will
218 need to present a certificate for the origin's host name, not that of
219 the alternative. Likewise, the Host header field ([RFC7230], Section
220 5.4) is still derived from the origin, not the alternative service
221 (just as it would if a CNAME were being used).
223 The changes MAY, however, be made visible in debugging tools,
224 consoles, etc.
226 Formally, an alternative service is identified by the combination of:
228 o An Application Layer Protocol Negotiation (ALPN) protocol name, as
229 per [RFC7301]
231 o A host, as per [RFC3986], Section 3.2.2
233 o A port, as per [RFC3986], Section 3.2.3
235 The ALPN protocol name is used to identify the application protocol
236 or suite of protocols used by the alternative service. Note that for
237 the purpose of this specification, an ALPN protocol name implicitly
238 includes TLS in the suite of protocols it identifies, unless
239 specified otherwise in its definition. In particular, the ALPN name
240 "http/1.1", registered by Section 6 of [RFC7301], identifies HTTP/1.1
241 over TLS.
243 Additionally, each alternative service MUST have:
245 o A freshness lifetime, expressed in seconds; see Section 2.2
247 There are many ways that a client could discover the alternative
248 service(s) associated with an origin. This document describes two
249 such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the
250 "ALTSVC" HTTP/2 frame type (Section 4).
252 The remainder of this section describes requirements that are common
253 to alternative services, regardless of how they are discovered.
255 2.1. Host Authentication
257 Clients MUST have reasonable assurances that the alternative service
258 is under control of and valid for the whole origin. This mitigates
259 the attack described in Section 9.2.
261 For the purposes of this document, "reasonable assurances" can be
262 established through use of a TLS-based protocol with the certificate
263 checks defined in [RFC2818]. Clients MAY impose additional criteria
264 for establishing reasonable assurances.
266 For example, if the origin's host is "www.example.com" and an
267 alternative is offered on "other.example.com" with the "h2" protocol,
268 and the certificate offered is valid for "www.example.com", the
269 client can use the alternative. However, if either is offered with
270 the "h2c" protocol, the client cannot use it, because there is no
271 mechanism (at the time of the publication of this specification) in
272 that protocol to establish the relationship between the origin and
273 the alternative.
275 2.2. Alternative Service Caching
277 Mechanisms for discovering alternative services also associate a
278 freshness lifetime with them; for example, the Alt-Svc header field
279 uses the "ma" parameter.
281 Clients can choose to use an alternative service instead of the
282 origin at any time when it is considered fresh; see Section 2.4 for
283 specific recommendations.
285 Clients with existing connections to an alternative service do not
286 need to stop using it when its freshness lifetime ends; the caching
287 mechanism is intended for limiting how long an alternative service
288 can be used for establishing new connections, not limiting the use of
289 existing ones.
291 Alternative services are fully authoritative for the origin in
292 question, including the ability to clear or update cached alternative
293 service entries, extend freshness lifetimes, and any other authority
294 the origin server would have.
296 When alternative services are used to send a client to the most
297 optimal server, a change in network configuration can result in
298 cached values becoming suboptimal. Therefore, clients SHOULD remove
299 from cache all alternative services that lack the "persist" flag with
300 the value "1" when they detect such a change, when information about
301 network state is available.
303 2.3. Requiring Server Name Indication
305 A client MUST NOT use a TLS-based alternative service unless the
306 client supports TLS Server Name Indication (SNI). This supports the
307 conservation of IP addresses on the alternative service host.
309 Note that the SNI information provided in TLS by the client will be
310 that of the origin, not the alternative (as will the Host HTTP header
311 field value).
313 2.4. Using Alternative Services
315 By their nature, alternative services are OPTIONAL: clients do not
316 need to use them. However, it is advantageous for clients to behave
317 in a predictable way when alternative services are used by servers,
318 to aid purposes like load balancing.
320 Therefore, if a client supporting this specification becomes aware of
321 an alternative service, the client SHOULD use that alternative
322 service for all requests to the associated origin as soon as it is
323 available, provided the alternative service information is fresh
324 (Section 2.2) and the security properties of the alternative service
325 protocol are desirable, as compared to the existing connection. A
326 viable alternative service is then treated in every way as the
327 origin; this includes the ability to advertise alternative services.
329 If a client becomes aware of multiple alternative services, it
330 chooses the most suitable according to its own criteria, keeping
331 security properties in mind. For example, an origin might advertise
332 multiple alternative services to notify clients of support for
333 multiple versions of HTTP.
335 A client configured to use a proxy for a given request SHOULD NOT
336 directly connect to an alternative service for this request, but
337 instead route it through that proxy.
339 When a client uses an alternative service for a request, it can
340 indicate this to the server using the Alt-Used header field
341 (Section 5).
343 The client does not need to block requests on any existing
344 connection; it can be used until the alternative connection is
345 established. However, if the security properties of the existing
346 connection are weak (for example, cleartext HTTP/1.1) then it might
347 make sense to block until the new connection is fully available in
348 order to avoid information leakage.
350 Furthermore, if the connection to the alternative service fails or is
351 unresponsive, the client MAY fall back to using the origin or another
352 alternative service. Note, however, that this could be the basis of
353 a downgrade attack, thus losing any enhanced security properties of
354 the alternative service. If the connection to the alternative
355 service does not negotiate the expected protocol (for example, ALPN
356 fails to negotiate h2, or an Upgrade request to h2c is not accepted),
357 the connection to the alternative service MUST be considered to have
358 failed.
360 3. The Alt-Svc HTTP Header Field
362 An HTTP(S) origin server can advertise the availability of
363 alternative services to clients by adding an Alt-Svc header field to
364 responses.
366 Alt-Svc = clear / 1#alt-value
367 clear = %s"clear"; "clear", case-sensitive
368 alt-value = alternative *( OWS ";" OWS parameter )
369 alternative = protocol-id "=" alt-authority
370 protocol-id = token ; percent-encoded ALPN protocol name
371 alt-authority = quoted-string ; containing [ uri-host ] ":" port
372 parameter = token "=" ( token / quoted-string )
374 The field value consists either of a list of values, each of which
375 indicates one alternative service, or the keyword "clear".
377 A field value containing the special value "clear" indicates that the
378 origin requests all alternatives for that origin to be invalidated
379 (including those specified in the same response, in case of an
380 invalid reply containing both "clear" and alternative services).
382 ALPN protocol names are octet sequences with no additional
383 constraints on format. Octets not allowed in tokens ([RFC7230],
384 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
385 [RFC3986]. Consequently, the octet representing the percent
386 character "%" (hex 25) MUST be percent-encoded as well.
388 In order to have precisely one way to represent any ALPN protocol
389 name, the following additional constraints apply:
391 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if
392 they are valid token characters except "%", and
394 2. When using percent-encoding, uppercase hex digits MUST be used.
396 With these constraints, recipients can apply simple string comparison
397 to match protocol identifiers.
399 The "alt-authority" component consists of an OPTIONAL uri-host
400 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port
401 number.
403 For example:
405 Alt-Svc: h2=":8000"
407 This indicates the "h2" protocol ([RFC7540]) on the same host using
408 the indicated port 8000.
410 An example involving a change of host:
412 Alt-Svc: h2="new.example.org:80"
414 This indicates the "h2" protocol on the host "new.example.org",
415 running on port 80. Note that the "quoted-string" syntax needs to be
416 used because ":" is not an allowed character in "token".
418 Examples for protocol name escaping:
420 +--------------------+-------------+---------------------+
421 | ALPN protocol name | protocol-id | Note |
422 +--------------------+-------------+---------------------+
423 | h2 | h2 | No escaping needed |
424 +--------------------+-------------+---------------------+
425 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
426 +--------------------+-------------+---------------------+
427 | x%y | x%25y | "%" needs escaping |
428 +--------------------+-------------+---------------------+
430 Alt-Svc MAY occur in any HTTP response message, regardless of the
431 status code. Note that recipients of Alt-Svc can ignore the header
432 field (and are required to in some situations; see Sections 2.1 and
433 6).
435 The Alt-Svc field value can have multiple values:
437 Alt-Svc: h2="alt.example.com:8000", h2=":443"
439 When multiple values are present, the order of the values reflects
440 the server's preference (with the first value being the most
441 preferred alternative).
443 The value(s) advertised by Alt-Svc can be used by clients to open a
444 new connection to an alternative service. Subsequent requests can
445 start using this new connection immediately, or can continue using
446 the existing connection while the new connection is created.
448 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC
449 frame (Section 4). A single ALTSVC frame can be sent for a
450 connection; a new frame is not needed for every request. Note that,
451 despite this recommendation, Alt-Svc header fields remain valid in
452 responses delivered over HTTP/2.
454 Each "alt-value" is followed by an OPTIONAL semicolon-separated list
455 of additional parameters, each such "parameter" comprising a name and
456 a value.
458 This specification defines two parameters: "ma" and "persist",
459 defined in Section 3.1. Unknown parameters MUST be ignored. That
460 is, the values (alt-value) they appear in MUST be processed as if the
461 unknown parameter was not present.
463 New parameters can be defined in extension specifications (see
464 Section 7.3 for registration details).
466 Note that all field elements that allow "quoted-string" syntax MUST
467 be processed as per Section 3.2.6 of [RFC7230].
469 3.1. Caching Alt-Svc Header Field Values
471 When an alternative service is advertised using Alt-Svc, it is
472 considered fresh for 24 hours from generation of the message. This
473 can be modified with the 'ma' (max-age) parameter.
475 Syntax:
477 ma = delta-seconds; see [RFC7234], Section 1.2.1
479 The delta-seconds value indicates the number of seconds since the
480 response was generated the alternative service is considered fresh
481 for.
483 Alt-Svc: h2=":443"; ma=3600
485 See Section 4.2.3 of [RFC7234] for details of determining response
486 age.
488 For example, a response:
490 HTTP/1.1 200 OK
491 Content-Type: text/html
492 Cache-Control: max-age=600
493 Age: 30
494 Alt-Svc: h2=":8000"; ma=60
496 indicates that an alternative service is available and usable for the
497 next 60 seconds. However, the response has already been cached for
498 30 seconds (as per the Age header field value), so therefore the
499 alternative service is only fresh for the 30 seconds from when this
500 response was received, minus estimated transit time.
502 Note that the freshness lifetime for HTTP caching (here, 600 seconds)
503 does not affect caching of Alt-Svc values.
505 When an Alt-Svc response header field is received from an origin, its
506 value invalidates and replaces all cached alternative services for
507 that origin.
509 By default, cached alternative services will be cleared when the
510 client detects a network change. Alternative services that are
511 intended to be longer-lived (such as those that are not specific to
512 the client access network) can carry the "persist" parameter with a
513 value "1" as a hint that the service is potentially useful beyond a
514 network configuration change.
516 Syntax:
518 persist = "1"
520 For example:
522 Alt-Svc: h2=":443"; ma=2592000; persist=1
524 This specification only defines a single value for "persist".
525 Clients MUST ignore "persist" parameters with values other than "1".
527 See Section 2.2 for general requirements on caching alternative
528 services.
530 4. The ALTSVC HTTP/2 Frame
532 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the
533 availability of an alternative service to an HTTP/2 client.
535 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints
536 that do not support this frame will ignore it (as per the
537 extensibility rules defined in Section 4.1 of [RFC7540]).
539 An ALTSVC frame from a server to a client on a stream other than
540 stream 0 indicates that the conveyed alternative service is
541 associated with the origin of that stream.
543 An ALTSVC frame from a server to a client on stream 0 indicates that
544 the conveyed alternative service is associated with the origin
545 contained in the Origin field of the frame. An association with an
546 origin that the client does not consider authoritative for the
547 current connection MUST be ignored.
549 The ALTSVC frame type is 0xa (decimal 10).
551 +-------------------------------+-------------------------------+
552 | Origin-Len (16) | Origin? (*) ...
553 +-------------------------------+-------------------------------+
554 | Alt-Svc-Field-Value (*) ...
555 +---------------------------------------------------------------+
557 ALTSVC Frame Payload
559 The ALTSVC frame contains the following fields:
561 Origin-Len: An unsigned, 16-bit integer indicating the length, in
562 octets, of the Origin field.
564 Origin: An OPTIONAL sequence of characters containing the ASCII
565 serialization of an origin ([RFC6454], Section 6.2) that the
566 alternative service is applicable to.
568 Alt-Svc-Field-Value: A sequence of octets (length determined by
569 subtracting the length of all preceding fields from the frame
570 length) containing a value identical to the Alt-Svc field value
571 defined in Section 3 (ABNF production "Alt-Svc").
573 The ALTSVC frame does not define any flags.
575 The ALTSVC frame is intended for receipt by clients. A device acting
576 as a server MUST ignore it.
578 An ALTSVC frame on stream 0 with empty (length 0) "Origin"
579 information is invalid and MUST be ignored. An ALTSVC frame on a
580 stream other than stream 0 containing non-empty "Origin" information
581 is invalid and MUST be ignored.
583 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT
584 forward ALTSVC frames, though it can use the information contained in
585 ALTSVC frames in forming new ALTSVC frames to send to its own
586 clients.
588 Receiving an ALTSVC frame is semantically equivalent to receiving an
589 Alt-Svc header field. As a result, the ALTSVC frame causes
590 alternative services for the corresponding origin to be replaced.
591 Note that it would be unwise to mix the use of Alt-Svc header fields
592 with the use of ALTSVC frames, as the sequence of receipt might be
593 hard to predict.
595 5. The Alt-Used HTTP Header Field
597 The Alt-Used header field is used in requests to indicate the
598 identity of the alternative service in use, just as the Host header
599 field (Section 5.4 of [RFC7230]) identifies the host and port of the
600 origin.
602 Alt-Used = uri-host [ ":" port ]
604 Alt-Used is intended to allow alternative services to detect loops,
605 differentiate traffic for purposes of load balancing, and generally
606 to ensure that it is possible to identify the intended destination of
607 traffic, since introducing this information after a protocol is in
608 use has proven to be problematic.
610 When using an alternative service, clients SHOULD include an Alt-Used
611 header field in all requests.
613 For example:
615 GET /thing HTTP/1.1
616 Host: origin.example.com
617 Alt-Used: alternate.example.net
619 6. The 421 Misdirected Request HTTP Status Code
621 The 421 (Misdirected Request) status code is defined in Section 9.1.2
622 of [RFC7540] to indicate that the current server instance is not
623 authoritative for the requested resource. This can be used to
624 indicate that an alternative service is not authoritative; see
625 Section 2).
627 Clients receiving 421 (Misdirected Request) from an alternative
628 service MUST remove the corresponding entry from its alternative
629 service cache (see Section 2.2) for that origin. Regardless of the
630 idempotency of the request method, they MAY retry the request, either
631 at another alternative server, or at the origin.
633 An Alt-Svc header field in a 421 (Misdirected Request) response MUST
634 be ignored.
636 7. IANA Considerations
638 7.1. Header Field Registrations
640 HTTP header fields are registered within the "Message Headers"
641 registry maintained at
642 .
644 This document defines the following HTTP header fields, so their
645 associated registry entries shall be added according to the permanent
646 registrations below (see [BCP90]):
648 +-------------------+----------+----------+-----------+
649 | Header Field Name | Protocol | Status | Reference |
650 +-------------------+----------+----------+-----------+
651 | Alt-Svc | http | standard | Section 3 |
652 | Alt-Used | http | standard | Section 5 |
653 +-------------------+----------+----------+-----------+
655 The change controller is: "IETF (iesg@ietf.org) - Internet
656 Engineering Task Force".
658 7.2. The ALTSVC HTTP/2 Frame Type
660 This document registers the ALTSVC frame type in the HTTP/2 Frame
661 Types registry ([RFC7540], Section 11.2).
663 Frame Type: ALTSVC
665 Code: 0xa
667 Specification: Section 4 of this document
669 7.3. Alt-Svc Parameter Registry
671 The HTTP Alt-Svc Parameter Registry defines the name space for
672 parameters. It will be created and maintained at (the suggested URI)
673 .
675 7.3.1. Procedure
677 A registration MUST include the following fields:
679 o Parameter Name
680 o Pointer to specification text
682 Values to be added to this name space require Expert Review (see
683 [RFC5226], Section 4.1).
685 7.3.2. Registrations
687 The HTTP Alt-Svc Parameter Registry is to be populated with the
688 registrations below:
690 +-------------------+-------------+
691 | Alt-Svc Parameter | Reference |
692 +-------------------+-------------+
693 | ma | Section 3.1 |
694 | persist | Section 3.1 |
695 +-------------------+-------------+
697 8. Internationalization Considerations
699 An internationalized domain name that appears in either the header
700 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed
701 using A-labels ([RFC5890], Section 2.3.2.1).
703 9. Security Considerations
705 9.1. Changing Ports
707 Using an alternative service implies accessing an origin's resources
708 on an alternative port, at a minimum. An attacker that can inject
709 alternative services and listen at the advertised port is therefore
710 able to hijack an origin. On certain servers, it is normal for users
711 to be able to control some personal pages available on a shared port,
712 and also to accept to requests on less-privileged ports.
714 For example, an attacker that can add HTTP response header fields to
715 some pages can redirect traffic for an entire origin to a different
716 port on the same host using the Alt-Svc header field; if that port is
717 under the attacker's control, they can thus masquerade as the HTTP
718 server.
720 This risk is mitigated by the requirements in Section 2.1.
722 On servers, this risk can also be reduced by restricting the ability
723 to advertise alternative services, and restricting who can open a
724 port for listening on that host.
726 9.2. Changing Hosts
728 When the host is changed due to the use of an alternative service, it
729 presents an opportunity for attackers to hijack communication to an
730 origin.
732 For example, if an attacker can convince a user agent to send all
733 traffic for "innocent.example.org" to "evil.example.com" by
734 successfully associating it as an alternative service, they can
735 masquerade as that origin. This can be done locally (see mitigations
736 in Section 9.1) or remotely (e.g., by an intermediary as a man-in-
737 the-middle attack).
739 This is the reason for the requirement in Section 2.1 that clients
740 have reasonable assurances that the alternative service is under
741 control of and valid for the whole origin; for example, presenting a
742 certificate for the origin proves that the alternative service is
743 authorized to serve traffic for the origin.
745 Note that this assurance is only as strong as the method used to
746 authenticate the alternative service. In particular, when TLS
747 authentication is used to do so, there are well-known exploits to
748 make an attacker's certificate appear as legitimate.
750 Alternative services could be used to persist such an attack. For
751 example, an intermediary could man-in-the-middle TLS-protected
752 communication to a target, and then direct all traffic to an
753 alternative service with a large freshness lifetime, so that the user
754 agent still directs traffic to the attacker even when not using the
755 intermediary.
757 Implementations MUST perform any certificate-pinning validation (such
758 as [RFC7469]) on alternative services just as they would on direct
759 connections to the origin. Implementations might also choose to add
760 other requirements around which certificates are acceptable for
761 alternative services.
763 9.3. Changing Protocols
765 When the ALPN protocol is changed due to the use of an alternative
766 service, the security properties of the new connection to the origin
767 can be different from that of the "normal" connection to the origin,
768 because the protocol identifier itself implies this.
770 For example, if an "https://" URI has a protocol advertised that does
771 not use some form of end-to-end encryption (most likely, TLS), it
772 violates the expectations for security that the URI scheme implies.
773 Therefore, clients cannot blindly use alternative services, but
774 instead evaluate the option(s) presented to assure that security
775 requirements and expectations of specifications, implementations and
776 end users are met.
778 9.4. Tracking Clients Using Alternative Services
780 Choosing an alternative service implies connecting to a new, server-
781 supplied host name. By using unique names, servers could conceivably
782 track client requests. Such tracking could follow users across
783 multiple networks, when the "persist" flag is used.
785 Clients that wish to prevent requests from being correlated can
786 decide not to use alternative services for multiple requests that
787 would not otherwise be allowed to be correlated.
789 In a user agent, any alternative service information MUST be removed
790 when origin-specific data is cleared (typically, when cookies
791 [RFC6265] are cleared).
793 9.5. Confusion Regarding Request Scheme
795 Some server-side HTTP applications make assumptions about security
796 based upon connection context; for example, equating being served
797 upon port 443 with the use of an "https://" URI and the various
798 security properties that implies.
800 This affects not only the security properties of the connection
801 itself, but also the state of the client at the other end of it; for
802 example, a Web browser treats "https://" URIs differently than
803 "http://" URIs in many ways, not just for purposes of protocol
804 handling.
806 Since one of the uses of Alternative Services is to allow a
807 connection to be migrated to a different protocol and port, these
808 applications can become confused about the security properties of a
809 given connection, sending information (for example, cookies and
810 content) that is intended for a secure context (such as an "https://"
811 URI) to a client that is not treating it as one.
813 This risk can be mitigated in servers by using the URI scheme
814 explicitly carried by the protocol (such as ":scheme" in HTTP/2 or
815 the "absolute form" of the request target in HTTP/1.1) as an
816 indication of security context, instead of other connection
817 properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
819 When the protocol does not explicitly carry the scheme (as is usually
820 the case for HTTP/1.1 over TLS), servers can mitigate this risk by
821 either assuming that all requests have an insecure context, or by
822 refraining from advertising alternative services for insecure schemes
823 (for example, HTTP).
825 10. References
827 10.1. Normative References
829 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
830 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
831 RFC2119, March 1997,
832 .
834 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
835 RFC2818, May 2000,
836 .
838 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
839 Resource Identifier (URI): Generic Syntax", STD 66,
840 RFC 3986, DOI 10.17487/RFC3986, January 2005,
841 .
843 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
844 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
845 DOI 10.17487/RFC5226, May 2008,
846 .
848 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
849 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
850 RFC5234, January 2008,
851 .
853 [RFC5890] Klensin, J., "Internationalized Domain Names for
854 Applications (IDNA): Definitions and Document Framework",
855 RFC 5890, DOI 10.17487/RFC5890, August 2010,
856 .
858 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
859 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066,
860 January 2011, .
862 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
863 DOI 10.17487/RFC6454, December 2011,
864 .
866 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
867 Protocol (HTTP/1.1): Message Syntax and Routing",
868 RFC 7230, DOI 10.17487/RFC7230, June 2014,
869 .
871 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
872 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
873 RFC 7234, DOI 10.17487/RFC7234, June 2014,
874 .
876 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile,
877 "Transport Layer Security (TLS) Application-Layer Protocol
878 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
879 July 2014, .
881 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
882 RFC 7405, DOI 10.17487/RFC7405, December 2014,
883 .
885 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
886 Transfer Protocol version 2", RFC 7540, DOI 10.17487/
887 RFC7540, May 2015,
888 .
890 10.2. Informative References
892 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
893 Procedures for Message Header Fields", BCP 90, RFC 3864,
894 September 2004, .
896 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
897 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
898 RFC5246, August 2008,
899 .
901 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
902 DOI 10.17487/RFC6265, April 2011,
903 .
905 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
906 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
907 April 2015, .
909 Appendix A. Change Log (to be removed by RFC Editor before publication)
911 A.1. Since draft-nottingham-httpbis-alt-svc-05
913 This is the first version after adoption of
914 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It
915 only contains editorial changes.
917 A.2. Since draft-ietf-httpbis-alt-svc-00
919 Selected 421 as proposed status code for "Not Authoritative".
921 Changed header field syntax to use percent-encoding of ALPN protocol
922 names ().
924 A.3. Since draft-ietf-httpbis-alt-svc-01
926 Updated HTTP/1.1 references.
928 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag
929 to address fingerprinting concerns
930 ().
932 Note that ALTSVC frame is preferred to Alt-Svc header field
933 ().
935 Incorporate ALTSRV frame
936 ().
938 Moved definition of status code 421 to HTTP/2.
940 Partly resolved .
942 A.4. Since draft-ietf-httpbis-alt-svc-02
944 Updated ALPN reference.
946 Resolved .
948 A.5. Since draft-ietf-httpbis-alt-svc-03
950 Renamed "Alt-Svc-Used" to "Alt-Used"
951 ().
953 Clarify ALTSVC Origin information requirements
954 ().
956 Remove/tune language with respect to tracking risks (see
957 ).
959 A.6. Since draft-ietf-httpbis-alt-svc-04
961 Mention tracking by alt-svc host name in Security Considerations
962 ().
964 "421 (Not Authoritative)" -> "421 (Misdirected Request)".
966 Allow the frame to carry multiple indicator and use the same payload
967 formats for both
968 ().
970 A.7. Since draft-ietf-httpbis-alt-svc-05
972 Go back to specifying the origin in Alt-Used, but make it a "SHOULD"
973 ().
975 Restore Origin field in ALT-SVC frame
976 ().
978 A.8. Since draft-ietf-httpbis-alt-svc-06
980 Disallow use of alternative services when the protocol might not
981 carry the scheme
982 ().
984 Align opp-sec and alt-svc
985 ().
987 alt svc frame on pushed (even and non-0) frame
988 ().
990 "browser" -> "user agent"
991 ().
993 ABNF for "parameter"
994 ().
996 Updated HTTP/2 reference.
998 A.9. Since draft-ietf-httpbis-alt-svc-07
1000 Alt-Svc alternative cache invalidation
1001 ().
1003 Unexpected Alt-Svc frames
1004 ().
1006 Associating Alt-Svc header with an origin
1007 ().
1009 ALPN identifiers in Alt-Svc
1010 ().
1012 Number of alternate services used
1013 ().
1015 Proxy and .pac interaction
1016 ().
1018 Need to define extensibility for alt-svc parameters
1019 ().
1021 Persistence of alternates across network changes
1022 ().
1024 Alt-Svc header with 421 status
1025 ().
1027 Incorporate several editorial improvements suggested by Mike Bishop
1028 (,
1029 ).
1031 Alt-Svc response header field in HTTP/2 frame
1032 ().
1034 A.10. Since draft-ietf-httpbis-alt-svc-08
1036 Remove left over text about ext-params, applying to an earlier
1037 version of Alt-Used (see
1038 ).
1040 Conflicts between Alt-Svc and ALPN
1041 ().
1043 Elevation of privilege
1044 ().
1046 Alternates of alternates
1047 ().
1049 Alt-Svc and Cert Pinning
1050 ().
1052 Using alt-svc on localhost (no change to spec, see
1053 ).
1055 IANA procedure for alt-svc parameters
1056 ().
1058 Alt-svc from https (1.1) to https (1.1)
1059 ().
1061 Alt-svc vs the ability to convey the scheme inside the protocol
1062 ().
1064 Reconciling MAY/can vs. SHOULD
1065 ().
1067 Typo in alt-svc caching example
1068 ().
1070 A.11. Since draft-ietf-httpbis-alt-svc-09
1072 Editorial improvements
1073 (,
1074 ,
1075 ,
1076 ,
1077 ,
1078 ,
1079 ,
1080 ).
1082 A.12. Since draft-ietf-httpbis-alt-svc-10
1084 Editorial improvements
1085 ().
1087 Use RFC 7405 ABNF extension
1088 ().
1090 A.13. Since draft-ietf-httpbis-alt-svc-11
1092 Security considerations wrt system ports
1093 ().
1095 A.14. Since draft-ietf-httpbis-alt-svc-12
1097 Editorial changes triggered by .
1100 Reasonable Assurances and H2C
1101 ().
1103 Appendix B. Acknowledgements
1105 Thanks to Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik
1106 Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson,
1107 Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard
1108 Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan for their
1109 feedback and suggestions.
1111 The Alt-Svc header field was influenced by the design of the
1112 Alternate-Protocol header field in SPDY.
1114 Authors' Addresses
1116 Mark Nottingham
1117 Akamai
1119 EMail: mnot@mnot.net
1120 URI: https://www.mnot.net/
1122 Patrick McManus
1123 Mozilla
1125 EMail: mcmanus@ducksong.com
1126 URI: https://mozillians.org/u/pmcmanus/
1128 Julian F. Reschke
1129 greenbytes GmbH
1131 EMail: julian.reschke@greenbytes.de
1132 URI: https://greenbytes.de/tech/webdav/