idnits 2.17.1
draft-ietf-httpbis-alt-svc-10.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 15, 2015) is 3054 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 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: 4 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: June 17, 2016 Mozilla
6 J. Reschke
7 greenbytes
8 December 15, 2015
10 HTTP Alternative Services
11 draft-ietf-httpbis-alt-svc-10
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 17, 2016.
50 Copyright Notice
52 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . 7
71 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 7
72 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 7
73 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 8
74 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 9
75 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 11
76 4. The ALTSVC HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 12
77 5. The Alt-Used HTTP Header Field . . . . . . . . . . . . . . . . 14
78 6. The 421 Misdirected Request HTTP Status Code . . . . . . . . . 14
79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
80 7.1. Header Field Registrations . . . . . . . . . . . . . . . . 14
81 7.2. The ALTSVC HTTP/2 Frame Type . . . . . . . . . . . . . . . 15
82 7.3. Alt-Svc Parameter Registry . . . . . . . . . . . . . . . . 15
83 7.3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
84 7.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 15
85 8. Internationalization Considerations . . . . . . . . . . . . . 16
86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
87 9.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 16
88 9.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 16
89 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17
90 9.4. Tracking Clients Using Alternative Services . . . . . . . 18
91 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18
92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
94 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
95 Appendix A. Change Log (to be removed by RFC Editor before
96 publication) . . . . . . . . . . . . . . . . . . . . 20
97 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20
98 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20
99 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20
100 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21
101 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21
102 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21
103 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21
104 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22
105 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22
106 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23
107 A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 24
108 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
110 1. Introduction
112 HTTP [RFC7230] conflates the identification of resources with their
113 location. In other words, "http://" (and "https://") URIs are used
114 to both name and find things to interact with.
116 In some cases, it is desirable to separate identification and
117 location in HTTP; keeping the same identifier for a resource, but
118 interacting with it at a different location on the network.
120 For example:
122 o An origin server might wish to redirect a client to a different
123 server when it is under load, or it has found a server in a
124 location that is more local to the client.
126 o An origin server might wish to offer access to its resources using
127 a new protocol (such as HTTP/2, see [RFC7540]) or one using
128 improved security (such as Transport Layer Security (TLS), see
129 [RFC5246]).
131 o An origin server might wish to segment its clients into groups of
132 capabilities, such as those supporting Server Name Indication
133 (SNI, see Section 3 of [RFC6066]) and those not supporting it, for
134 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] along with
156 the "#rule" extension defined in Section 7 of [RFC7230]. The rules
157 below are defined in [RFC5234], [RFC7230], and [RFC7234]:
159 DIGIT =
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 (see [RFC6454]) has resources that are
171 accessible through a different protocol / host / port combination, it
172 is said to 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; i.e., 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 NOT use alternative services with a host that is
258 different than the origin's without strong server authentication;
259 this mitigates the attack described in Section 9.2. One way to
260 achieve this is for the alternative to use TLS with a certificate
261 that is valid for that origin.
263 For example, if the origin's host is "www.example.com" and an
264 alternative is offered on "other.example.com" with the "h2" protocol,
265 and the certificate offered is valid for "www.example.com", the
266 client can use the alternative. However, if "other.example.com" is
267 offered with the "h2c" protocol, the client cannot use it, because
268 there is no mechanism in that protocol to establish strong server
269 authentication.
271 2.2. Alternative Service Caching
273 Mechanisms for discovering alternative services also associate a
274 freshness lifetime with them; for example, the Alt-Svc header field
275 uses the "ma" parameter.
277 Clients can choose to use an alternative service instead of the
278 origin at any time when it is considered fresh; see Section 2.4 for
279 specific recommendations.
281 Clients with existing connections to an alternative service do not
282 need to stop using it when its freshness lifetime ends; i.e., the
283 caching mechanism is intended for limiting how long an alternative
284 service can be used for establishing new connections, not limiting
285 the use of existing ones.
287 Alternative services are fully authoritative for the origin in
288 question, including the ability to clear or update cached alternative
289 service entries, extend freshness lifetimes, and any other authority
290 the origin server would have.
292 When alternative services are used to send a client to the most
293 optimal server, a change in network configuration can result in
294 cached values becoming suboptimal. Therefore, clients SHOULD remove
295 from cache all alternative services that lack the "persist" flag with
296 the value "1" when they detect such a change (when information about
297 network state is available).
299 2.3. Requiring Server Name Indication
301 A client MUST only use a TLS-based alternative service if the client
302 also supports TLS Server Name Indication (SNI). This supports the
303 conservation of IP addresses on the alternative service host.
305 Note that the SNI information provided in TLS by the client will be
306 that of the origin, not the alternative (as will the Host HTTP header
307 field value).
309 2.4. Using Alternative Services
311 By their nature, alternative services are OPTIONAL: clients do not
312 need to use them. However, it is advantageous for clients to behave
313 in a predictable way when they are used by servers (e.g., for load
314 balancing).
316 Therefore, if a client becomes aware of an alternative service, the
317 client SHOULD use that alternative service for all requests to the
318 associated origin as soon as it is available, provided the
319 alternative service information is fresh (Section 2.2) and the
320 security properties of the alternative service protocol are
321 desirable, as compared to the existing connection. A viable
322 alternative service is then treated in every way as the origin; this
323 includes the ability to advertise alternative services.
325 If a client becomes aware of multiple alternative services, it MAY
326 choose the most suitable according to its own criteria (again,
327 keeping security properties in mind). For example, an origin might
328 advertise multiple alternative services to notify clients of support
329 for multiple versions of HTTP.
331 A client configured to use a proxy for a given request SHOULD NOT
332 directly connect to an alternative service for this request, but
333 instead route it through that proxy.
335 When a client uses an alternative service for a request, it can
336 indicate this to the server using the Alt-Used header field
337 (Section 5).
339 The client does not need to block requests on any existing
340 connection; it can be used until the alternative connection is
341 established. However, if the security properties of the existing
342 connection are weak (e.g. cleartext HTTP/1.1) then it might make
343 sense to block until the new connection is fully available in order
344 to avoid information leakage.
346 Furthermore, if the connection to the alternative service fails or is
347 unresponsive, the client MAY fall back to using the origin or another
348 alternative service. Note, however, that this could be the basis of
349 a downgrade attack, thus losing any enhanced security properties of
350 the alternative service. If the connection to the alternative
351 service does not negotiate the expected protocol (for example, ALPN
352 fails to negotiate h2, or an Upgrade request to h2c is not accepted),
353 the connection to the alternative service MUST be considered to have
354 failed.
356 3. The Alt-Svc HTTP Header Field
358 An HTTP(S) origin server can advertise the availability of
359 alternative services to clients by adding an Alt-Svc header field to
360 responses.
362 Alt-Svc = clear / 1#alt-value
363 clear = %x63.6C.65.61.72; "clear", case-sensitive
364 alt-value = alternative *( OWS ";" OWS parameter )
365 alternative = protocol-id "=" alt-authority
366 protocol-id = token ; percent-encoded ALPN protocol name
367 alt-authority = quoted-string ; containing [ uri-host ] ":" port
368 parameter = token "=" ( token / quoted-string )
370 The field value consists either of a list of values, each of which
371 indicating one alternative service, or the keyword "clear".
373 A field value containing the special value "clear" indicates that the
374 origin requests all alternatives for that origin to be invalidated
375 (including those specified in the same response, in case of an
376 invalid reply containing both "clear" and alternative services).
378 ALPN protocol names are octet sequences with no additional
379 constraints on format. Octets not allowed in tokens ([RFC7230],
380 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
381 [RFC3986]. Consequently, the octet representing the percent
382 character "%" (hex 25) MUST be percent-encoded as well.
384 In order to have precisely one way to represent any ALPN protocol
385 name, the following additional constraints apply:
387 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if
388 they are valid token characters except "%", and
390 2. When using percent-encoding, uppercase hex digits MUST be used.
392 With these constraints, recipients can apply simple string comparison
393 to match protocol identifiers.
395 The "alt-authority" component consists of an OPTIONAL uri-host
396 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port
397 number.
399 For example:
401 Alt-Svc: h2=":8000"
403 This indicates the "h2" protocol ([RFC7540]) on the same host using
404 the indicated port 8000.
406 An example involving a change of host:
408 Alt-Svc: h2="new.example.org:80"
410 This indicates the "h2" protocol on the host "new.example.org",
411 running on port 80. Note that the "quoted-string" syntax needs to be
412 used because ":" is not an allowed character in "token".
414 Examples for protocol name escaping:
416 +--------------------+-------------+---------------------+
417 | ALPN protocol name | protocol-id | Note |
418 +--------------------+-------------+---------------------+
419 | h2 | h2 | No escaping needed |
420 +--------------------+-------------+---------------------+
421 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
422 +--------------------+-------------+---------------------+
423 | x%y | x%25y | "%" needs escaping |
424 +--------------------+-------------+---------------------+
426 Alt-Svc MAY occur in any HTTP response message, regardless of the
427 status code. Note that recipients of Alt-Svc are free to ignore the
428 header field (and indeed need to in some situations; see Sections 2.1
429 and 6).
431 The Alt-Svc field value can have multiple values:
433 Alt-Svc: h2c=":8000", h2=":443"
435 When multiple values are present, the order of the values reflects
436 the server's preference (with the first value being the most
437 preferred alternative).
439 The value(s) advertised by Alt-Svc can be used by clients to open a
440 new connection to an alternative service. Subsequent requests can
441 start using this new connection immediately, or can continue using
442 the existing connection while the new connection is created.
444 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC
445 frame (Section 4). A single ALTSVC frame can be sent for a
446 connection; a new frame is not needed for every request. Note that,
447 despite this recommendation, Alt-Svc header fields remain valid in
448 responses delivered over HTTP/2.
450 Each "alt-value" is followed by an OPTIONAL semicolon-separated list
451 of additional parameters, each such "parameter" comprising a name and
452 a value.
454 This specification defines two parameters: "ma" and "persist",
455 defined in Section 3.1. Unknown parameters MUST be ignored, that is
456 the values (alt-value) they appear in MUST be processed as if the
457 unknown parameter was not present.
459 New parameters can be defined in extension specifications (see
460 Section 7.3 for registration details).
462 Note that all field elements that allow "quoted-string" syntax MUST
463 be processed as per Section 3.2.6 of [RFC7230].
465 3.1. Caching Alt-Svc Header Field Values
467 When an alternative service is advertised using Alt-Svc, it is
468 considered fresh for 24 hours from generation of the message. This
469 can be modified with the 'ma' (max-age) parameter.
471 Syntax:
473 ma = delta-seconds; see [RFC7234], Section 1.2.1
475 The delta-seconds value indicates the number of seconds since the
476 response was generated the alternative service is considered fresh
477 for.
479 Alt-Svc: h2=":443"; ma=3600
481 See Section 4.2.3 of [RFC7234] for details of determining response
482 age.
484 For example, a response:
486 HTTP/1.1 200 OK
487 Content-Type: text/html
488 Cache-Control: max-age=600
489 Age: 30
490 Alt-Svc: h2c=":8000"; ma=60
492 indicates that an alternative service is available and usable for the
493 next 60 seconds. However, the response has already been cached for
494 30 seconds (as per the Age header field value), so therefore the
495 alternative service is only fresh for the 30 seconds from when this
496 response was received, minus estimated transit time.
498 Note that the freshness lifetime for HTTP caching (here, 600 seconds)
499 does not affect caching of Alt-Svc values.
501 When an Alt-Svc response header field is received from an origin, its
502 value invalidates and replaces all cached alternative services for
503 that origin.
505 By default, cached alternative services will be cleared when the
506 client detects a network change. Alternative services that are
507 intended to be longer-lived (e.g., those that are not specific to the
508 client access network) can carry the "persist" parameter with a value
509 "1" as a hint that the service is potentially useful beyond a network
510 configuration change.
512 Syntax:
514 persist = 1DIGIT
516 For example:
518 Alt-Svc: h2=":443"; ma=2592000; persist=1
520 This specification only a defines a single value for "persist";
521 others can be defined in future specifications. Clients MUST ignore
522 "persist" parameters with unknown values.
524 See Section 2.2 for general requirements on caching alternative
525 services.
527 4. The ALTSVC HTTP/2 Frame
529 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the
530 availability of an alternative service to an HTTP/2 client.
532 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints
533 that do not support this frame can safely ignore it.
535 An ALTSVC frame from a server to a client on a stream other than
536 stream 0 indicates that the conveyed alternative service is
537 associated with the origin of that stream.
539 An ALTSVC frame from a server to a client on stream 0 indicates that
540 the conveyed alternative service is associated with the origin
541 contained in the Origin field of the frame. An association with an
542 origin that the client does not consider authoritative for the
543 current connection MUST be ignored.
545 The ALTSVC frame type is 0xa (decimal 10).
547 +-------------------------------+-------------------------------+
548 | Origin-Len (16) | Origin? (*) ...
549 +-------------------------------+-------------------------------+
550 | Alt-Svc-Field-Value (*) ...
551 +---------------------------------------------------------------+
553 ALTSVC Frame Payload
555 The ALTSVC frame contains the following fields:
557 Origin-Len: An unsigned, 16-bit integer indicating the length, in
558 octets, of the Origin field.
560 Origin: An OPTIONAL sequence of characters containing the ASCII
561 serialization of an origin ([RFC6454], Section 6.2) that the
562 alternative service is applicable to.
564 Alt-Svc-Field-Value: A sequence of octets (length determined by
565 subtracting the length of all preceding fields from the frame
566 length) containing a value identical to the Alt-Svc field value
567 defined in Section 3 (ABNF production "Alt-Svc").
569 The ALTSVC frame does not define any flags.
571 The ALTSVC frame is intended for receipt by clients; a server that
572 receives an ALTSVC frame can safely ignore it.
574 An ALTSVC frame on stream 0 with empty (length 0) "Origin"
575 information is invalid and MUST be ignored. An ALTSVC frame on a
576 stream other than stream 0 containing non-empty "Origin" information
577 is invalid and MUST be ignored.
579 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT
580 forward ALTSVC frames, though it can use the information contained in
581 ALTSVC frames in forming new ALTSVC frames to send to its own
582 clients.
584 Receiving an ALTSVC frame is semantically equivalent to receiving an
585 Alt-Svc header field. As a result, the ALTSVC frame causes
586 alternative services for the corresponding origin to be replaced.
587 Note that it would be unwise to mix the use of Alt-Svc header fields
588 with the use of ALTSVC frames, as the sequence of receipt might be
589 hard to predict.
591 5. The Alt-Used HTTP Header Field
593 The Alt-Used header field is used in requests to indicate the
594 identity of the alternative service in use, just as the Host header
595 field (Section 5.4 of [RFC7230]) identifies the host and port of the
596 origin.
598 Alt-Used = uri-host [ ":" port ]
600 Alt-Used is intended to allow alternative services to detect loops,
601 differentiate traffic for purposes of load balancing, and generally
602 to ensure that it is possible to identify the intended destination of
603 traffic, since introducing this information after a protocol is in
604 use has proven to be problematic.
606 When using an alternative service, clients SHOULD include an Alt-Used
607 header field in all requests.
609 For example:
611 GET /thing HTTP/1.1
612 Host: origin.example.com
613 Alt-Used: alternate.example.net
615 6. The 421 Misdirected Request HTTP Status Code
617 The 421 (Misdirected Request) status code is defined in Section 9.1.2
618 of [RFC7540] to indicate that the current server instance is not
619 authoritative for the requested resource. This can be used to
620 indicate that an alternative service is not authoritative; see
621 Section 2).
623 Clients receiving 421 (Misdirected Request) from an alternative
624 service MUST remove the corresponding entry from its alternative
625 service cache (see Section 2.2) for that origin. Regardless of the
626 idempotency of the request method, they MAY retry the request, either
627 at another alternative server, or at the origin.
629 An Alt-Svc header field in a 421 (Misdirected Request) response MUST
630 be ignored.
632 7. IANA Considerations
634 7.1. Header Field Registrations
636 HTTP header fields are registered within the "Message Headers"
637 registry maintained at
638 .
640 This document defines the following HTTP header fields, so their
641 associated registry entries shall be added according to the permanent
642 registrations below (see [BCP90]):
644 +-------------------+----------+----------+-----------+
645 | Header Field Name | Protocol | Status | Reference |
646 +-------------------+----------+----------+-----------+
647 | Alt-Svc | http | standard | Section 3 |
648 | Alt-Used | http | standard | Section 5 |
649 +-------------------+----------+----------+-----------+
651 The change controller is: "IETF (iesg@ietf.org) - Internet
652 Engineering Task Force".
654 7.2. The ALTSVC HTTP/2 Frame Type
656 This document registers the ALTSVC frame type in the HTTP/2 Frame
657 Types registry ([RFC7540], Section 11.2).
659 Frame Type: ALTSVC
661 Code: 0xa
663 Specification: Section 4 of this document
665 7.3. Alt-Svc Parameter Registry
667 The HTTP Alt-Svc Parameter Registry defines the name space for
668 parameters. It will be created and maintained at (the suggested URI)
669 .
671 7.3.1. Procedure
673 A registration MUST include the following fields:
675 o Parameter Name
677 o Pointer to specification text
679 Values to be added to this name space require Expert Review (see
680 [RFC5226], Section 4.1).
682 7.3.2. Registrations
684 The HTTP Alt-Svc Parameter Registry is to be populated with the
685 registrations below:
687 +-------------------+-------------+
688 | Alt-Svc Parameter | Reference |
689 +-------------------+-------------+
690 | ma | Section 3.1 |
691 | persist | Section 3.1 |
692 +-------------------+-------------+
694 8. Internationalization Considerations
696 An internationalized domain name that appears in either the header
697 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed
698 using A-labels ([RFC5890], Section 2.3.2.1).
700 9. Security Considerations
702 9.1. Changing Ports
704 Using an alternative service implies accessing an origin's resources
705 on an alternative port, at a minimum. An attacker that can inject
706 alternative services and listen at the advertised port is therefore
707 able to hijack an origin. On certain servers, it is normal for users
708 to be able to control some personal pages available on a shared port,
709 and also to accept to requests on less-privileged ports.
711 For example, an attacker that can add HTTP response header fields to
712 some pages can redirect traffic for an entire origin to a different
713 port on the same host using the Alt-Svc header field; if that port is
714 under the attacker's control, they can thus masquerade as the HTTP
715 server.
717 On servers, this risk can be reduced by restricting the ability to
718 advertise alternative services, and restricting who can open a port
719 for listening on that host. Clients can reduce this risk by imposing
720 stronger requirements (e.g. strong authentication) when moving from
721 System Ports to User or Dynamic Ports, or from User Ports to Dynamic
722 Ports, as defined in Section 6 of [RFC6335].
724 It is always valid for a client to ignore an alternative service
725 advertisement which does not meet its implementation-specific
726 security requirements. Servers can increase the likelihood of
727 clients using the alternative service by providing strong
728 authentication even when not required.
730 9.2. Changing Hosts
732 When the host is changed due to the use of an alternative service, it
733 presents an opportunity for attackers to hijack communication to an
734 origin.
736 For example, if an attacker can convince a user agent to send all
737 traffic for "innocent.example.org" to "evil.example.com" by
738 successfully associating it as an alternative service, they can
739 masquerade as that origin. This can be done locally (see mitigations
740 in Section 9.1) or remotely (e.g., by an intermediary as a man-in-
741 the-middle attack).
743 This is the reason for the requirement in Section 2.1 that any
744 alternative service with a host different from the origin's be
745 strongly authenticated with the origin's identity; i.e., presenting a
746 certificate for the origin proves that the alternative service is
747 authorized to serve traffic for the origin.
749 However, this authorization is only as strong as the method used to
750 authenticate the alternative service. In particular, there are well-
751 known exploits to make an attacker's certificate appear as
752 legitimate.
754 Alternative services could be used to persist such an attack; for
755 example, an intermediary could man-in-the-middle TLS-protected
756 communication to a target, and then direct all traffic to an
757 alternative service with a large freshness lifetime, so that the user
758 agent still directs traffic to the attacker even when not using the
759 intermediary.
761 Implementations MUST perform any certificate-pinning validation (e.g.
762 [RFC7469]) on alternative services just as they would on direct
763 connections to the origin. Implementations might also choose to add
764 other requirements around which certificates are acceptable for
765 alternative services.
767 9.3. Changing Protocols
769 When the ALPN protocol is changed due to the use of an alternative
770 service, the security properties of the new connection to the origin
771 can be different from that of the "normal" connection to the origin,
772 because the protocol identifier itself implies this.
774 For example, if an "https://" URI has a protocol advertised that does
775 not use some form of end-to-end encryption (most likely, TLS), it
776 violates the expectations for security that the URI scheme implies.
778 Therefore, clients cannot blindly use alternative services, but
779 instead evaluate the option(s) presented to assure that security
780 requirements and expectations (of specifications, implementations and
781 end users) are met.
783 9.4. Tracking Clients Using Alternative Services
785 Choosing an alternative service implies connecting to a new, server-
786 supplied host name. By using many different (potentially unique)
787 host names, servers could conceivably track client requests. Such
788 tracking could follow users across multiple networks, when the
789 "persist" flag is used.
791 Clients concerned by the additional fingerprinting can choose to
792 ignore alternative service advertisements.
794 In a user agent, any alternative service information MUST be removed
795 when origin-specific data is cleared (for instance, when cookies are
796 cleared).
798 9.5. Confusion Regarding Request Scheme
800 Some server-side HTTP applications make assumptions about security
801 based upon connection context; for example, equating being served
802 upon port 443 with the use of an "https://" URI (and the various
803 security properties that implies).
805 This affects not only the security properties of the connection
806 itself, but also the state of the client at the other end of it; for
807 example, a Web browser treats "https://" URIs differently than
808 "http://" URIs in many ways, not just for purposes of protocol
809 handling.
811 Since one of the uses of Alternative Services is to allow a
812 connection to be migrated to a different protocol and port, these
813 applications can become confused about the security properties of a
814 given connection, sending information (e.g., cookies, content) that
815 is intended for a secure context (e.g., an "https://" URI) to a
816 client that is not treating it as one.
818 This risk can be mitigated in servers by using the URI scheme
819 explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the
820 "absolute form" of the request target in HTTP/1.1) as an indication
821 of security context, instead of other connection properties
822 ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
824 When the protocol does not explicitly carry the scheme (e.g., as is
825 usually the case for HTTP/1.1 over TLS, servers can, mitigate this
826 risk by either assuming that all requests have an insecure context,
827 or by refraining from advertising alternative services for insecure
828 schemes (such as HTTP).
830 10. References
831 10.1. Normative References
833 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
834 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
835 RFC2119, March 1997,
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. 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 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
882 Transfer Protocol version 2", RFC 7540, DOI 10.17487/
883 RFC7540, May 2015,
884 .
886 10.2. Informative References
888 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
889 Procedures for Message Header Fields", BCP 90, RFC 3864,
890 September 2004, .
892 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
893 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
894 RFC5246, August 2008,
895 .
897 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
898 Cheshire, "Internet Assigned Numbers Authority (IANA)
899 Procedures for the Management of the Service Name and
900 Transport Protocol Port Number Registry", RFC 6335,
901 DOI 10.17487/RFC6335, August 2011,
902 .
904 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
905 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
906 April 2015, .
908 Appendix A. Change Log (to be removed by RFC Editor before publication)
910 A.1. Since draft-nottingham-httpbis-alt-svc-05
912 This is the first version after adoption of
913 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It
914 only contains editorial changes.
916 A.2. Since draft-ietf-httpbis-alt-svc-00
918 Selected 421 as proposed status code for "Not Authoritative".
920 Changed header field syntax to use percent-encoding of ALPN protocol
921 names ().
923 A.3. Since draft-ietf-httpbis-alt-svc-01
925 Updated HTTP/1.1 references.
927 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag
928 to address fingerprinting concerns
929 ().
931 Note that ALTSVC frame is preferred to Alt-Svc header field
932 ().
934 Incorporate ALTSRV frame
935 ().
937 Moved definition of status code 421 to HTTP/2.
939 Partly resolved .
941 A.4. Since draft-ietf-httpbis-alt-svc-02
943 Updated ALPN reference.
945 Resolved .
947 A.5. Since draft-ietf-httpbis-alt-svc-03
949 Renamed "Alt-Svc-Used" to "Alt-Used"
950 ().
952 Clarify ALTSVC Origin information requirements
953 ().
955 Remove/tune language with respect to tracking risks (see
956 ).
958 A.6. Since draft-ietf-httpbis-alt-svc-04
960 Mention tracking by alt-svc host name in Security Considerations
961 ().
963 "421 (Not Authoritative)" -> "421 (Misdirected Request)".
965 Allow the frame to carry multiple indicator and use the same payload
966 formats for both
967 ().
969 A.7. Since draft-ietf-httpbis-alt-svc-05
971 Go back to specifying the origin in Alt-Used, but make it a "SHOULD"
972 ().
974 Restore Origin field in ALT-SVC frame
975 ().
977 A.8. Since draft-ietf-httpbis-alt-svc-06
979 Disallow use of alternative services when the protocol might not
980 carry the scheme
981 ().
983 Align opp-sec and alt-svc
984 ().
986 alt svc frame on pushed (even and non-0) frame
987 ().
989 "browser" -> "user agent"
990 ().
992 ABNF for "parameter"
993 ().
995 Updated HTTP/2 reference.
997 A.9. Since draft-ietf-httpbis-alt-svc-07
999 Alt-Svc alternative cache invalidation
1000 ().
1002 Unexpected Alt-Svc frames
1003 ().
1005 Associating Alt-Svc header with an origin
1006 ().
1008 ALPN identifiers in Alt-Svc
1009 ().
1011 Number of alternate services used
1012 ().
1014 Proxy and .pac interaction
1015 ().
1017 Need to define extensibility for alt-svc parameters
1018 ().
1020 Persistence of alternates across network changes
1021 ().
1023 Alt-Svc header with 421 status
1024 ().
1026 Incorporate several editorial improvements suggested by Mike Bishop
1027 (,
1028 ).
1030 Alt-Svc response header field in HTTP/2 frame
1031 ().
1033 A.10. Since draft-ietf-httpbis-alt-svc-08
1035 Remove left over text about ext-params, applying to an earlier
1036 version of Alt-Used (see
1037 ).
1039 Conflicts between Alt-Svc and ALPN
1040 ().
1042 Elevation of privilege
1043 ().
1045 Alternates of alternates
1046 ().
1048 Alt-Svc and Cert Pinning
1049 ().
1051 Using alt-svc on localhost (no change to spec, see
1052 ).
1054 IANA procedure for alt-svc parameters
1055 ().
1057 Alt-svc from https (1.1) to https (1.1)
1058 ().
1060 Alt-svc vs the ability to convey the scheme inside the protocol
1061 ().
1063 Reconciling MAY/can vs. SHOULD
1064 ().
1066 Typo in alt-svc caching example
1067 ().
1069 A.11. Since draft-ietf-httpbis-alt-svc-09
1071 Editorial improvements
1072 (,
1073 ,
1074 ,
1075 ,
1076 ,
1077 ,
1078 ,
1079 ).
1081 Appendix B. Acknowledgements
1083 Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy
1084 Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew
1085 Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury,
1086 Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and
1087 suggestions.
1089 The Alt-Svc header field was influenced by the design of the
1090 Alternate-Protocol header field in SPDY.
1092 Authors' Addresses
1094 Mark Nottingham
1095 Akamai
1097 EMail: mnot@mnot.net
1098 URI: https://www.mnot.net/
1100 Patrick McManus
1101 Mozilla
1103 EMail: mcmanus@ducksong.com
1104 URI: https://mozillians.org/u/pmcmanus/
1106 Julian F. Reschke
1107 greenbytes GmbH
1109 EMail: julian.reschke@greenbytes.de
1110 URI: https://greenbytes.de/tech/webdav/