idnits 2.17.1
draft-ietf-httpbis-alt-svc-13.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 1, 2016) is 2940 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 2, 2016 Mozilla
6 J. Reschke
7 greenbytes
8 March 1, 2016
10 HTTP Alternative Services
11 draft-ietf-httpbis-alt-svc-13
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 2, 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]. Other means of establishing them MUST
264 be documented in an RFC that updates this specification. Clients MAY
265 impose additional criteria for establishing reasonable assurances.
267 For example, if the origin's host is "www.example.com" and an
268 alternative is offered on "other.example.com" with the "h2" protocol,
269 and the certificate offered is valid for "www.example.com", the
270 client can use the alternative. However, if either is offered with
271 the "h2c" protocol, the client cannot use it, because there is no
272 mechanism (at the time of the publication of this specification) in
273 that protocol to establish the relationship between the origin and
274 the alternative.
276 2.2. Alternative Service Caching
278 Mechanisms for discovering alternative services also associate a
279 freshness lifetime with them; for example, the Alt-Svc header field
280 uses the "ma" parameter.
282 Clients can choose to use an alternative service instead of the
283 origin at any time when it is considered fresh; see Section 2.4 for
284 specific recommendations.
286 Clients with existing connections to an alternative service do not
287 need to stop using it when its freshness lifetime ends; the caching
288 mechanism is intended for limiting how long an alternative service
289 can be used for establishing new connections, not limiting the use of
290 existing ones.
292 Alternative services are fully authoritative for the origin in
293 question, including the ability to clear or update cached alternative
294 service entries, extend freshness lifetimes, and any other authority
295 the origin server would have.
297 When alternative services are used to send a client to the most
298 optimal server, a change in network configuration can result in
299 cached values becoming suboptimal. Therefore, clients SHOULD remove
300 from cache all alternative services that lack the "persist" flag with
301 the value "1" when they detect such a change, when information about
302 network state is available.
304 2.3. Requiring Server Name Indication
306 A client MUST only use a TLS-based alternative service if the client
307 also supports TLS Server Name Indication (SNI). This supports the
308 conservation of IP addresses on the alternative service host.
310 Note that the SNI information provided in TLS by the client will be
311 that of the origin, not the alternative (as will the Host HTTP header
312 field value).
314 2.4. Using Alternative Services
316 By their nature, alternative services are OPTIONAL: clients do not
317 need to use them. However, it is advantageous for clients to behave
318 in a predictable way when alternative services are used by servers,
319 to aid purposes like load balancing.
321 Therefore, if a client becomes aware of an alternative service, the
322 client SHOULD use that alternative service for all requests to the
323 associated origin as soon as it is available, provided the
324 alternative service information is fresh (Section 2.2) and the
325 security properties of the alternative service protocol are
326 desirable, as compared to the existing connection. A viable
327 alternative service is then treated in every way as the origin; this
328 includes the ability to advertise alternative services.
330 If a client becomes aware of multiple alternative services, it
331 chooses the most suitable according to its own criteria, keeping
332 security properties in mind. For example, an origin might advertise
333 multiple alternative services to notify clients of support for
334 multiple versions of HTTP.
336 A client configured to use a proxy for a given request SHOULD NOT
337 directly connect to an alternative service for this request, but
338 instead route it through that proxy.
340 When a client uses an alternative service for a request, it can
341 indicate this to the server using the Alt-Used header field
342 (Section 5).
344 The client does not need to block requests on any existing
345 connection; it can be used until the alternative connection is
346 established. However, if the security properties of the existing
347 connection are weak (for example, cleartext HTTP/1.1) then it might
348 make sense to block until the new connection is fully available in
349 order to avoid information leakage.
351 Furthermore, if the connection to the alternative service fails or is
352 unresponsive, the client MAY fall back to using the origin or another
353 alternative service. Note, however, that this could be the basis of
354 a downgrade attack, thus losing any enhanced security properties of
355 the alternative service. If the connection to the alternative
356 service does not negotiate the expected protocol (for example, ALPN
357 fails to negotiate h2, or an Upgrade request to h2c is not accepted),
358 the connection to the alternative service MUST be considered to have
359 failed.
361 3. The Alt-Svc HTTP Header Field
363 An HTTP(S) origin server can advertise the availability of
364 alternative services to clients by adding an Alt-Svc header field to
365 responses.
367 Alt-Svc = clear / 1#alt-value
368 clear = %s"clear"; "clear", case-sensitive
369 alt-value = alternative *( OWS ";" OWS parameter )
370 alternative = protocol-id "=" alt-authority
371 protocol-id = token ; percent-encoded ALPN protocol name
372 alt-authority = quoted-string ; containing [ uri-host ] ":" port
373 parameter = token "=" ( token / quoted-string )
375 The field value consists either of a list of values, each of which
376 indicates one alternative service, or the keyword "clear".
378 A field value containing the special value "clear" indicates that the
379 origin requests all alternatives for that origin to be invalidated
380 (including those specified in the same response, in case of an
381 invalid reply containing both "clear" and alternative services).
383 ALPN protocol names are octet sequences with no additional
384 constraints on format. Octets not allowed in tokens ([RFC7230],
385 Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
386 [RFC3986]. Consequently, the octet representing the percent
387 character "%" (hex 25) MUST be percent-encoded as well.
389 In order to have precisely one way to represent any ALPN protocol
390 name, the following additional constraints apply:
392 1. Octets in the ALPN protocol name MUST NOT be percent-encoded if
393 they are valid token characters except "%", and
395 2. When using percent-encoding, uppercase hex digits MUST be used.
397 With these constraints, recipients can apply simple string comparison
398 to match protocol identifiers.
400 The "alt-authority" component consists of an OPTIONAL uri-host
401 ("host" in Section 3.2.2 of [RFC3986]), a colon (":"), and a port
402 number.
404 For example:
406 Alt-Svc: h2=":8000"
408 This indicates the "h2" protocol ([RFC7540]) on the same host using
409 the indicated port 8000.
411 An example involving a change of host:
413 Alt-Svc: h2="new.example.org:80"
415 This indicates the "h2" protocol on the host "new.example.org",
416 running on port 80. Note that the "quoted-string" syntax needs to be
417 used because ":" is not an allowed character in "token".
419 Examples for protocol name escaping:
421 +--------------------+-------------+---------------------+
422 | ALPN protocol name | protocol-id | Note |
423 +--------------------+-------------+---------------------+
424 | h2 | h2 | No escaping needed |
425 +--------------------+-------------+---------------------+
426 | w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
427 +--------------------+-------------+---------------------+
428 | x%y | x%25y | "%" needs escaping |
429 +--------------------+-------------+---------------------+
431 Alt-Svc MAY occur in any HTTP response message, regardless of the
432 status code. Note that recipients of Alt-Svc can ignore the header
433 field (and are required to in some situations; see Sections 2.1 and
434 6).
436 The Alt-Svc field value can have multiple values:
438 Alt-Svc: h2="alt.example.com:8000", h2=":443"
440 When multiple values are present, the order of the values reflects
441 the server's preference (with the first value being the most
442 preferred alternative).
444 The value(s) advertised by Alt-Svc can be used by clients to open a
445 new connection to an alternative service. Subsequent requests can
446 start using this new connection immediately, or can continue using
447 the existing connection while the new connection is created.
449 When using HTTP/2 ([RFC7540]), servers SHOULD instead send an ALTSVC
450 frame (Section 4). A single ALTSVC frame can be sent for a
451 connection; a new frame is not needed for every request. Note that,
452 despite this recommendation, Alt-Svc header fields remain valid in
453 responses delivered over HTTP/2.
455 Each "alt-value" is followed by an OPTIONAL semicolon-separated list
456 of additional parameters, each such "parameter" comprising a name and
457 a value.
459 This specification defines two parameters: "ma" and "persist",
460 defined in Section 3.1. Unknown parameters MUST be ignored. That
461 is, the values (alt-value) they appear in MUST be processed as if the
462 unknown parameter was not present.
464 New parameters can be defined in extension specifications (see
465 Section 7.3 for registration details).
467 Note that all field elements that allow "quoted-string" syntax MUST
468 be processed as per Section 3.2.6 of [RFC7230].
470 3.1. Caching Alt-Svc Header Field Values
472 When an alternative service is advertised using Alt-Svc, it is
473 considered fresh for 24 hours from generation of the message. This
474 can be modified with the 'ma' (max-age) parameter.
476 Syntax:
478 ma = delta-seconds; see [RFC7234], Section 1.2.1
480 The delta-seconds value indicates the number of seconds since the
481 response was generated the alternative service is considered fresh
482 for.
484 Alt-Svc: h2=":443"; ma=3600
486 See Section 4.2.3 of [RFC7234] for details of determining response
487 age.
489 For example, a response:
491 HTTP/1.1 200 OK
492 Content-Type: text/html
493 Cache-Control: max-age=600
494 Age: 30
495 Alt-Svc: h2=":8000"; ma=60
497 indicates that an alternative service is available and usable for the
498 next 60 seconds. However, the response has already been cached for
499 30 seconds (as per the Age header field value), so therefore the
500 alternative service is only fresh for the 30 seconds from when this
501 response was received, minus estimated transit time.
503 Note that the freshness lifetime for HTTP caching (here, 600 seconds)
504 does not affect caching of Alt-Svc values.
506 When an Alt-Svc response header field is received from an origin, its
507 value invalidates and replaces all cached alternative services for
508 that origin.
510 By default, cached alternative services will be cleared when the
511 client detects a network change. Alternative services that are
512 intended to be longer-lived (such as those that are not specific to
513 the client access network) can carry the "persist" parameter with a
514 value "1" as a hint that the service is potentially useful beyond a
515 network configuration change.
517 Syntax:
519 persist = "1"
521 For example:
523 Alt-Svc: h2=":443"; ma=2592000; persist=1
525 This specification only defines a single value for "persist".
526 Clients MUST ignore "persist" parameters with values other than "1".
528 See Section 2.2 for general requirements on caching alternative
529 services.
531 4. The ALTSVC HTTP/2 Frame
533 The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the
534 availability of an alternative service to an HTTP/2 client.
536 The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints
537 that do not support this frame will ignore it (as per the
538 extensibility rules defined in Section 4.1 of [RFC7540]).
540 An ALTSVC frame from a server to a client on a stream other than
541 stream 0 indicates that the conveyed alternative service is
542 associated with the origin of that stream.
544 An ALTSVC frame from a server to a client on stream 0 indicates that
545 the conveyed alternative service is associated with the origin
546 contained in the Origin field of the frame. An association with an
547 origin that the client does not consider authoritative for the
548 current connection MUST be ignored.
550 The ALTSVC frame type is 0xa (decimal 10).
552 +-------------------------------+-------------------------------+
553 | Origin-Len (16) | Origin? (*) ...
554 +-------------------------------+-------------------------------+
555 | Alt-Svc-Field-Value (*) ...
556 +---------------------------------------------------------------+
558 ALTSVC Frame Payload
560 The ALTSVC frame contains the following fields:
562 Origin-Len: An unsigned, 16-bit integer indicating the length, in
563 octets, of the Origin field.
565 Origin: An OPTIONAL sequence of characters containing the ASCII
566 serialization of an origin ([RFC6454], Section 6.2) that the
567 alternative service is applicable to.
569 Alt-Svc-Field-Value: A sequence of octets (length determined by
570 subtracting the length of all preceding fields from the frame
571 length) containing a value identical to the Alt-Svc field value
572 defined in Section 3 (ABNF production "Alt-Svc").
574 The ALTSVC frame does not define any flags.
576 The ALTSVC frame is intended for receipt by clients. A device acting
577 as a server MUST ignore it.
579 An ALTSVC frame on stream 0 with empty (length 0) "Origin"
580 information is invalid and MUST be ignored. An ALTSVC frame on a
581 stream other than stream 0 containing non-empty "Origin" information
582 is invalid and MUST be ignored.
584 The ALTSVC frame is processed hop-by-hop. An intermediary MUST NOT
585 forward ALTSVC frames, though it can use the information contained in
586 ALTSVC frames in forming new ALTSVC frames to send to its own
587 clients.
589 Receiving an ALTSVC frame is semantically equivalent to receiving an
590 Alt-Svc header field. As a result, the ALTSVC frame causes
591 alternative services for the corresponding origin to be replaced.
592 Note that it would be unwise to mix the use of Alt-Svc header fields
593 with the use of ALTSVC frames, as the sequence of receipt might be
594 hard to predict.
596 5. The Alt-Used HTTP Header Field
598 The Alt-Used header field is used in requests to indicate the
599 identity of the alternative service in use, just as the Host header
600 field (Section 5.4 of [RFC7230]) identifies the host and port of the
601 origin.
603 Alt-Used = uri-host [ ":" port ]
605 Alt-Used is intended to allow alternative services to detect loops,
606 differentiate traffic for purposes of load balancing, and generally
607 to ensure that it is possible to identify the intended destination of
608 traffic, since introducing this information after a protocol is in
609 use has proven to be problematic.
611 When using an alternative service, clients SHOULD include an Alt-Used
612 header field in all requests.
614 For example:
616 GET /thing HTTP/1.1
617 Host: origin.example.com
618 Alt-Used: alternate.example.net
620 6. The 421 Misdirected Request HTTP Status Code
622 The 421 (Misdirected Request) status code is defined in Section 9.1.2
623 of [RFC7540] to indicate that the current server instance is not
624 authoritative for the requested resource. This can be used to
625 indicate that an alternative service is not authoritative; see
626 Section 2).
628 Clients receiving 421 (Misdirected Request) from an alternative
629 service MUST remove the corresponding entry from its alternative
630 service cache (see Section 2.2) for that origin. Regardless of the
631 idempotency of the request method, they MAY retry the request, either
632 at another alternative server, or at the origin.
634 An Alt-Svc header field in a 421 (Misdirected Request) response MUST
635 be ignored.
637 7. IANA Considerations
639 7.1. Header Field Registrations
641 HTTP header fields are registered within the "Message Headers"
642 registry maintained at
643 .
645 This document defines the following HTTP header fields, so their
646 associated registry entries shall be added according to the permanent
647 registrations below (see [BCP90]):
649 +-------------------+----------+----------+-----------+
650 | Header Field Name | Protocol | Status | Reference |
651 +-------------------+----------+----------+-----------+
652 | Alt-Svc | http | standard | Section 3 |
653 | Alt-Used | http | standard | Section 5 |
654 +-------------------+----------+----------+-----------+
656 The change controller is: "IETF (iesg@ietf.org) - Internet
657 Engineering Task Force".
659 7.2. The ALTSVC HTTP/2 Frame Type
661 This document registers the ALTSVC frame type in the HTTP/2 Frame
662 Types registry ([RFC7540], Section 11.2).
664 Frame Type: ALTSVC
666 Code: 0xa
668 Specification: Section 4 of this document
670 7.3. Alt-Svc Parameter Registry
672 The HTTP Alt-Svc Parameter Registry defines the name space for
673 parameters. It will be created and maintained at (the suggested URI)
674 .
676 7.3.1. Procedure
678 A registration MUST include the following fields:
680 o Parameter Name
681 o Pointer to specification text
683 Values to be added to this name space require Expert Review (see
684 [RFC5226], Section 4.1).
686 7.3.2. Registrations
688 The HTTP Alt-Svc Parameter Registry is to be populated with the
689 registrations below:
691 +-------------------+-------------+
692 | Alt-Svc Parameter | Reference |
693 +-------------------+-------------+
694 | ma | Section 3.1 |
695 | persist | Section 3.1 |
696 +-------------------+-------------+
698 8. Internationalization Considerations
700 An internationalized domain name that appears in either the header
701 field (Section 3) or the HTTP/2 frame (Section 4) MUST be expressed
702 using A-labels ([RFC5890], Section 2.3.2.1).
704 9. Security Considerations
706 9.1. Changing Ports
708 Using an alternative service implies accessing an origin's resources
709 on an alternative port, at a minimum. An attacker that can inject
710 alternative services and listen at the advertised port is therefore
711 able to hijack an origin. On certain servers, it is normal for users
712 to be able to control some personal pages available on a shared port,
713 and also to accept to requests on less-privileged ports.
715 For example, an attacker that can add HTTP response header fields to
716 some pages can redirect traffic for an entire origin to a different
717 port on the same host using the Alt-Svc header field; if that port is
718 under the attacker's control, they can thus masquerade as the HTTP
719 server.
721 This risk is mitigated by the requirements in Section 2.1.
723 On servers, this risk can also be reduced by restricting the ability
724 to advertise alternative services, and restricting who can open a
725 port for listening on that host.
727 9.2. Changing Hosts
729 When the host is changed due to the use of an alternative service, it
730 presents an opportunity for attackers to hijack communication to an
731 origin.
733 For example, if an attacker can convince a user agent to send all
734 traffic for "innocent.example.org" to "evil.example.com" by
735 successfully associating it as an alternative service, they can
736 masquerade as that origin. This can be done locally (see mitigations
737 in Section 9.1) or remotely (e.g., by an intermediary as a man-in-
738 the-middle attack).
740 This is the reason for the requirement in Section 2.1 that clients
741 have reasonable assurances that the alternative service is under
742 control of and valid for the whole origin; presenting a certificate
743 for the origin proves that the alternative service is authorized to
744 serve traffic for the origin.
746 Note that this assurance is only as strong as the method used to
747 authenticate the alternative service. In particular, when TLS
748 authentication is used to do so, there are well-known exploits to
749 make an attacker's certificate appear as legitimate.
751 Alternative services could be used to persist such an attack. For
752 example, an intermediary could man-in-the-middle TLS-protected
753 communication to a target, and then direct all traffic to an
754 alternative service with a large freshness lifetime, so that the user
755 agent still directs traffic to the attacker even when not using the
756 intermediary.
758 Implementations MUST perform any certificate-pinning validation (such
759 as [RFC7469]) on alternative services just as they would on direct
760 connections to the origin. Implementations might also choose to add
761 other requirements around which certificates are acceptable for
762 alternative services.
764 9.3. Changing Protocols
766 When the ALPN protocol is changed due to the use of an alternative
767 service, the security properties of the new connection to the origin
768 can be different from that of the "normal" connection to the origin,
769 because the protocol identifier itself implies this.
771 For example, if an "https://" URI has a protocol advertised that does
772 not use some form of end-to-end encryption (most likely, TLS), it
773 violates the expectations for security that the URI scheme implies.
774 Therefore, clients cannot blindly use alternative services, but
775 instead evaluate the option(s) presented to assure that security
776 requirements and expectations of specifications, implementations and
777 end users are met.
779 9.4. Tracking Clients Using Alternative Services
781 Choosing an alternative service implies connecting to a new, server-
782 supplied host name. By using unique names, servers could conceivably
783 track client requests. Such tracking could follow users across
784 multiple networks, when the "persist" flag is used.
786 Clients that wish to prevent requests from being correlated can
787 decide not to use alternative services for multiple requests that
788 would not otherwise be allowed to be correlated.
790 In a user agent, any alternative service information MUST be removed
791 when origin-specific data is cleared (typically, when cookies
792 [RFC6265] are cleared).
794 9.5. Confusion Regarding Request Scheme
796 Some server-side HTTP applications make assumptions about security
797 based upon connection context; for example, equating being served
798 upon port 443 with the use of an "https://" URI and the various
799 security properties that implies.
801 This affects not only the security properties of the connection
802 itself, but also the state of the client at the other end of it; for
803 example, a Web browser treats "https://" URIs differently than
804 "http://" URIs in many ways, not just for purposes of protocol
805 handling.
807 Since one of the uses of Alternative Services is to allow a
808 connection to be migrated to a different protocol and port, these
809 applications can become confused about the security properties of a
810 given connection, sending information (for example, cookies and
811 content) that is intended for a secure context (such as an "https://"
812 URI) to a client that is not treating it as one.
814 This risk can be mitigated in servers by using the URI scheme
815 explicitly carried by the protocol (such as ":scheme" in HTTP/2 or
816 the "absolute form" of the request target in HTTP/1.1) as an
817 indication of security context, instead of other connection
818 properties ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
820 When the protocol does not explicitly carry the scheme (as is usually
821 the case for HTTP/1.1 over TLS), servers can mitigate this risk by
822 either assuming that all requests have an insecure context, or by
823 refraining from advertising alternative services for insecure
824 schemes, for example HTTP.
826 10. References
828 10.1. Normative References
830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
831 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
832 RFC2119, March 1997,
833 .
835 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
836 RFC2818, May 2000,
837 .
839 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
840 Resource Identifier (URI): Generic Syntax", STD 66,
841 RFC 3986, DOI 10.17487/RFC3986, January 2005,
842 .
844 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
845 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
846 DOI 10.17487/RFC5226, May 2008,
847 .
849 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
850 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
851 RFC5234, January 2008,
852 .
854 [RFC5890] Klensin, J., "Internationalized Domain Names for
855 Applications (IDNA): Definitions and Document Framework",
856 RFC 5890, DOI 10.17487/RFC5890, August 2010,
857 .
859 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
860 Extension Definitions", RFC 6066, DOI 10.17487/RFC6066,
861 January 2011, .
863 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
864 DOI 10.17487/RFC6454, December 2011,
865 .
867 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
868 Protocol (HTTP/1.1): Message Syntax and Routing",
869 RFC 7230, DOI 10.17487/RFC7230, June 2014,
870 .
872 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
873 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
874 RFC 7234, DOI 10.17487/RFC7234, June 2014,
875 .
877 [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile,
878 "Transport Layer Security (TLS) Application-Layer Protocol
879 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
880 July 2014, .
882 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
883 RFC 7405, DOI 10.17487/RFC7405, December 2014,
884 .
886 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
887 Transfer Protocol version 2", RFC 7540, DOI 10.17487/
888 RFC7540, May 2015,
889 .
891 10.2. Informative References
893 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
894 Procedures for Message Header Fields", BCP 90, RFC 3864,
895 September 2004, .
897 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
898 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
899 RFC5246, August 2008,
900 .
902 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
903 DOI 10.17487/RFC6265, April 2011,
904 .
906 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
907 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469,
908 April 2015, .
910 Appendix A. Change Log (to be removed by RFC Editor before publication)
912 A.1. Since draft-nottingham-httpbis-alt-svc-05
914 This is the first version after adoption of
915 draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It
916 only contains editorial changes.
918 A.2. Since draft-ietf-httpbis-alt-svc-00
920 Selected 421 as proposed status code for "Not Authoritative".
922 Changed header field syntax to use percent-encoding of ALPN protocol
923 names ().
925 A.3. Since draft-ietf-httpbis-alt-svc-01
927 Updated HTTP/1.1 references.
929 Renamed "Service" to "Alt-Svc-Used" and reduced information to a flag
930 to address fingerprinting concerns
931 ().
933 Note that ALTSVC frame is preferred to Alt-Svc header field
934 ().
936 Incorporate ALTSRV frame
937 ().
939 Moved definition of status code 421 to HTTP/2.
941 Partly resolved .
943 A.4. Since draft-ietf-httpbis-alt-svc-02
945 Updated ALPN reference.
947 Resolved .
949 A.5. Since draft-ietf-httpbis-alt-svc-03
951 Renamed "Alt-Svc-Used" to "Alt-Used"
952 ().
954 Clarify ALTSVC Origin information requirements
955 ().
957 Remove/tune language with respect to tracking risks (see
958 ).
960 A.6. Since draft-ietf-httpbis-alt-svc-04
962 Mention tracking by alt-svc host name in Security Considerations
963 ().
965 "421 (Not Authoritative)" -> "421 (Misdirected Request)".
967 Allow the frame to carry multiple indicator and use the same payload
968 formats for both
969 ().
971 A.7. Since draft-ietf-httpbis-alt-svc-05
973 Go back to specifying the origin in Alt-Used, but make it a "SHOULD"
974 ().
976 Restore Origin field in ALT-SVC frame
977 ().
979 A.8. Since draft-ietf-httpbis-alt-svc-06
981 Disallow use of alternative services when the protocol might not
982 carry the scheme
983 ().
985 Align opp-sec and alt-svc
986 ().
988 alt svc frame on pushed (even and non-0) frame
989 ().
991 "browser" -> "user agent"
992 ().
994 ABNF for "parameter"
995 ().
997 Updated HTTP/2 reference.
999 A.9. Since draft-ietf-httpbis-alt-svc-07
1001 Alt-Svc alternative cache invalidation
1002 ().
1004 Unexpected Alt-Svc frames
1005 ().
1007 Associating Alt-Svc header with an origin
1008 ().
1010 ALPN identifiers in Alt-Svc
1011 ().
1013 Number of alternate services used
1014 ().
1016 Proxy and .pac interaction
1017 ().
1019 Need to define extensibility for alt-svc parameters
1020 ().
1022 Persistence of alternates across network changes
1023 ().
1025 Alt-Svc header with 421 status
1026 ().
1028 Incorporate several editorial improvements suggested by Mike Bishop
1029 (,
1030 ).
1032 Alt-Svc response header field in HTTP/2 frame
1033 ().
1035 A.10. Since draft-ietf-httpbis-alt-svc-08
1037 Remove left over text about ext-params, applying to an earlier
1038 version of Alt-Used (see
1039 ).
1041 Conflicts between Alt-Svc and ALPN
1042 ().
1044 Elevation of privilege
1045 ().
1047 Alternates of alternates
1048 ().
1050 Alt-Svc and Cert Pinning
1051 ().
1053 Using alt-svc on localhost (no change to spec, see
1054 ).
1056 IANA procedure for alt-svc parameters
1057 ().
1059 Alt-svc from https (1.1) to https (1.1)
1060 ().
1062 Alt-svc vs the ability to convey the scheme inside the protocol
1063 ().
1065 Reconciling MAY/can vs. SHOULD
1066 ().
1068 Typo in alt-svc caching example
1069 ().
1071 A.11. Since draft-ietf-httpbis-alt-svc-09
1073 Editorial improvements
1074 (,
1075 ,
1076 ,
1077 ,
1078 ,
1079 ,
1080 ,
1081 ).
1083 A.12. Since draft-ietf-httpbis-alt-svc-10
1085 Editorial improvements
1086 ().
1088 Use RFC 7405 ABNF extension
1089 ().
1091 A.13. Since draft-ietf-httpbis-alt-svc-11
1093 Security considerations wrt system ports
1094 ().
1096 A.14. Since draft-ietf-httpbis-alt-svc-12
1098 Editorial changes triggered by .
1101 Reasonable Assurances and H2C
1102 ().
1104 Appendix B. Acknowledgements
1106 Thanks to Adam Langley, Bence Beky, Chris Lonvick, Eliot Lear, Erik
1107 Nygren, Guy Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson,
1108 Matthew Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard
1109 Bradbury, Stephen Farrell, Stephen Ludin, and Will Chan for their
1110 feedback and suggestions.
1112 The Alt-Svc header field was influenced by the design of the
1113 Alternate-Protocol header field in SPDY.
1115 Authors' Addresses
1117 Mark Nottingham
1118 Akamai
1120 EMail: mnot@mnot.net
1121 URI: https://www.mnot.net/
1123 Patrick McManus
1124 Mozilla
1126 EMail: mcmanus@ducksong.com
1127 URI: https://mozillians.org/u/pmcmanus/
1129 Julian F. Reschke
1130 greenbytes GmbH
1132 EMail: julian.reschke@greenbytes.de
1133 URI: https://greenbytes.de/tech/webdav/