idnits 2.17.1 draft-nottingham-variants-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC7234, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC7234, updated by this document, for RFC5378 checks: 2007-12-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2017) is 2369 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) -- Looks like a reference, but probably isn't: '1' on line 634 -- Looks like a reference, but probably isn't: '2' on line 636 -- Looks like a reference, but probably isn't: '3' on line 638 -- Looks like a reference, but probably isn't: '4' on line 640 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-15) exists of draft-ietf-httpbis-client-hints-04 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft Fastly 4 Updates: 7234 (if approved) October 30, 2017 5 Intended status: Standards Track 6 Expires: May 3, 2018 8 HTTP Representation Variants 9 draft-nottingham-variants-01 11 Abstract 13 This specification introduces the HTTP "Variants" response header 14 field to communicate what representations are available for a given 15 resource, and the companion "Variant-Key" response header field to 16 indicate which representation was selected. It is an augmentation of 17 the "Vary" mechanism in HTTP caching. 19 Note to Readers 21 _RFC EDITOR: please remove this section before publication_ 23 The issues list for this draft can be found at 24 https://github.com/mnot/I-D/labels/variants [1]. 26 The most recent (often, unpublished) draft is at 27 https://mnot.github.io/I-D/variants/ [2]. 29 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 30 pages/variants [3]. 32 See also the draft's current status in the IETF datatracker, at 33 https://datatracker.ietf.org/doc/draft-nottingham-variants/ [4]. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 3, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 70 2. The "Variants" HTTP Header Field . . . . . . . . . . . . . . 4 71 2.1. Relationship to Vary . . . . . . . . . . . . . . . . . . 6 72 3. The "Variant-Key" HTTP Header Field . . . . . . . . . . . . . 6 73 4. Defining Content Negotiation Using Variants . . . . . . . . . 7 74 5. Cache Behaviour . . . . . . . . . . . . . . . . . . . . . . . 7 75 5.1. Find Available Keys . . . . . . . . . . . . . . . . . . . 9 76 5.2. Example of Cache Behaviour . . . . . . . . . . . . . . . 9 77 6. Example Headers . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.1. Single Variant . . . . . . . . . . . . . . . . . . . . . 10 79 6.2. Multiple Variants . . . . . . . . . . . . . . . . . . . . 11 80 6.3. Partial Coverage . . . . . . . . . . . . . . . . . . . . 11 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 10.2. Informative References . . . . . . . . . . . . . . . . . 14 87 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 Appendix A. Variants for Existing Content Negotiation Mechanisms 14 89 A.1. Accept-Encoding . . . . . . . . . . . . . . . . . . . . . 14 90 A.2. Accept-Language . . . . . . . . . . . . . . . . . . . . . 15 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 HTTP proactive content negotiation ([RFC7231], Section 3.4.1) is 96 starting to be used more widely again. The most widely seen use - 97 determining a response's content-coding - is being joined by renewed 98 interest in negotiation for language and other, newer attributes (for 99 example, see [I-D.ietf-httpbis-client-hints]). 101 Successfully reusing negotiated responses that have been stored in a 102 HTTP cache requires establishment of a secondary cache key 103 ([RFC7234], Section 4.1) using the Vary header ([RFC7231], 104 Section 7.1.4), which identifies the request headers that form the 105 secondary cache key for a given response. 107 HTTP's caching model allows a certain amount of latitude in 108 normalising request header fields identified by Vary to match those 109 stored in the cache, so as to increase the chances of a cache hit 110 while still respecting the semantics of that header. However, this 111 is often inadequate; even with understanding of the headers' 112 semantics to facilitate such normalisation, a cache does not know 113 enough about the possible alternative representations available on 114 the origin server to make an appropriate decision. 116 For example, if a cache has stored the following request/response 117 pair: 119 GET /foo HTTP/1.1 120 Host: www.example.com 121 Accept-Language: en;q=1.0, fr;q=0.5 123 HTTP/1.1 200 OK 124 Content-Type: text/html 125 Content-Language: fr 126 Vary: Accept-Language 127 Transfer-Encoding: chunked 129 [French content] 131 Provided that the cache has full knowledge of the semantics of 132 Accept-Language and Content-Language, it will know that a French 133 representation is available and might be able to infer that an 134 English representation is not available. But, it does not know (for 135 example) whether a Japanese representation is available without 136 making another request, thereby incurring possibly unnecessary 137 latency. 139 This specification introduces the HTTP Variants response header field 140 (Section 2) to enumerate the available variant representations on the 141 origin server, to provide clients and caches with enough information 142 to properly satisfy requests - either by selecting a response from 143 cache or by forwarding the request towards the origin - by following 144 an algorithm defined in Section 5. 146 Its companion the Variant-Key response header field (Section 3) 147 indicates which representation was selected, so that it can be 148 reliably reused in the future. 150 This mechanism requires that proactive content negotiation mechanisms 151 define how they use it; see Section 4. It is best suited for 152 negotiation over request headers that are well-understood. It also 153 works best when content negotiation takes place over a constrained 154 set of representations; since each variant needs to be listed in the 155 header field, it is ill-suited for open-ended sets of 156 representations. 158 It can be seen as a simpler version of the Alternates header field 159 introduced by [RFC2295]; unlike that mechanism, Variants does not 160 require specification of each combination of attributes, and does not 161 assume that each combination has a unique URL. 163 1.1. Notational Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 167 "OPTIONAL" in this document are to be interpreted as described in BCP 168 14 [RFC2119] [RFC8174] when, and only when, they appear in all 169 capitals, as shown here. 171 This specification uses the Augmented Backus-Naur Form (ABNF) 172 notation of [RFC5234] with a list extension, defined in Section 7 of 173 [RFC7230], that allows for compact definition of comma-separated 174 lists using a '#' operator (similar to how the '*' operator indicates 175 repetition). 177 Additionally, it uses the "field-name", "OWS" and "token" rules from 178 [RFC7230]. 180 2. The "Variants" HTTP Header Field 182 The Variants HTTP response header field indicates what 183 representations are available for a given resource at the time that 184 the response is produced, by enumerating the request header fields 185 that it varies on, along with the values that are available for each. 187 Variants = 1#variant-item 188 variant-item = field-name *( OWS ";" OWS available-value ) 189 available-value = token 191 Each "variant-item" indicates a request header field that carries a 192 value that clients might proactively negotiate for; each parameter on 193 it indicates a value for which there is an available representation 194 on the origin server. 196 So, given this example header field: 198 Variants: Accept-Encoding;gzip 200 a recipient can infer that the only content-coding available for that 201 resource is "gzip" (along with the "identity" non-encoding; see 202 Appendix A.1). 204 Given: 206 Variants: accept-encoding 208 a recipient can infer that no content-codings (beyond identity) are 209 supported. Note that as always, field-name is case-insensitive. 211 A more complex example: 213 Variants: Accept-Encoding;gzip;br, Accept-Language;en ;fr 215 Here, recipients can infer that two content-codings in addition to 216 "identity" are available, as well as two content languages. Note 217 that, as with all HTTP header fields that use the "#" list rule (see 218 [RFC7230], Section 7), they might occur in the same header field or 219 separately, like this: 221 Variants: Accept-Encoding;gzip;brotli 222 Variants: Accept-Language;en ;fr 224 The ordering of available-values after the field-name is significant, 225 as it might be used by the header's algorithm for selecting a 226 response (see Appendix A.1 for an example of this). 228 The ordering of the request header fields themselves indicates 229 descending application of preferences; for example, in the headers 230 above, a cache will serve gzip'd content regardless of language if it 231 is available. 233 Origin servers SHOULD consistently send Variant header fields on all 234 cacheable (as per [RFC7234], Section 3) responses for a resource, 235 since its absence will trigger caches to fall back to Vary 236 processing. 238 Likewise, servers MUST send the Variant-Key response header field 239 when sending Variants. 241 2.1. Relationship to Vary 243 Caches that fully implement this specification SHOULD ignore request 244 header fields in the "Vary" header for the purposes of secondary 245 cache key calculation ([RFC7234], Section 4.1) when their semantics 246 are implemented as per this specification and their corresponding 247 response header field is listed in "Variants". 249 If any member of the Vary header does not have a corresponding 250 variant that is understood by the implementation, it is still subject 251 to the requirements there. 253 3. The "Variant-Key" HTTP Header Field 255 The Variant-Key HTTP response header field is used to indicate the 256 value(s) from the Variants header field that identify the 257 representation it occurs within. 259 Variant-Key = 1#available-value 261 Each value indicates the selected available-value, in the same order 262 as the variants listed in the Variants header field. 264 Therefore, Variant-Key MUST be the same length (in comma-separated 265 members) as Variants, and each member MUST correspond in position to 266 its companion in Variants. 268 For example: 270 Variants: Content-Encoding;gzip;br, Content-Language;en ;fr 271 Variant-Key: gzip, fr 273 This header pair indicates that the representation is used for 274 responses that have a "gzip" content-coding and "fr" content- 275 language. 277 Note that the contents of Variant-Key are only used to indicate what 278 request attributes are identified with the response containing it; 279 this is different from headers like Content-Encoding, which indicate 280 attributes of the response. In the example above, it might be that a 281 gzip'd version of the French content is not available, in which case 282 it will not include "Content-Encoding: gzip", but still have "gzip" 283 in Variant-Key. 285 4. Defining Content Negotiation Using Variants 287 To be usable with Variants, proactive content negotiation mechanisms 288 need to be specified to take advantage of it. Specifically, they: 290 o MUST define a request header field that advertises the clients 291 preferences or capabilities, whose field-name SHOULD begin with 292 "Accept-". 294 o MUST define the syntax of available-values that will occur in 295 Variants and Variant-Key. 297 o MUST define an algorithm for selecting a result. It MUST return a 298 list of available-values that are suitable for the request, in 299 order of preference, given the value of the request header 300 nominated above and an available-values list from the Variants 301 header. If the result is an empty list, it implies that the cache 302 cannot satisfy the request. 304 Appendix A fulfils these requirements for some existing proactive 305 content negotiation mechanisms in HTTP. 307 5. Cache Behaviour 309 Caches that implement the Variants header field and the relevant 310 semantics of the field-name it contains can use that knowledge to 311 either select an appropriate stored representation, or forward the 312 request if no appropriate representation is stored. 314 They do so by running this algorithm (or its functional equivalent) 315 upon receiving a request, incoming-request: 317 1. Let selected-responses be a list of the stored responses suitable 318 for reuse as defined in [RFC7234] Section 4, excepting the 319 requirement to calculate a secondary cache key. 321 2. Order selected-responses by the "Date" header field, most recent 322 to least recent. 324 3. If the freshest (as per [RFC7234], Section 4.2) has one or more 325 "Variants" header field(s): 327 1. Select one member of selected_responses and let its 328 "Variants" header field-value(s) be variants-header. This 329 SHOULD be the most recent response, but MAY be from an older 330 one as long as it is still fresh. 332 2. Let sorted-variants be an empty list. 334 3. For each variant in variants-header: 336 1. If variant's field-name corresponds to the response 337 header field identified by a content negotiation 338 mechanism that the implementation supports: 340 1. Let request-value be the field-value of the request 341 header field(s) identified by the content negotiation 342 mechanism. 344 2. Let available-values be a list containing all 345 available-value for the variant. 347 3. Let sorted-values be the result of running the 348 algorithm defined by the content negotiation 349 mechanism with request-value and available-values. 351 4. Append sorted-values to sorted-variants. 353 At this point, sorted-variants will be a list of lists, each 354 member of the top-level list corresponding to a variant-item 355 in the Variants header field-value, containing zero or more 356 items indicating available-values that are acceptable to the 357 client, in order of preference, greatest to least. 359 4. If any member of sorted-variants is an empty list, stop 360 processing and forward the request towards the origin, since 361 an acceptable response is not stored in the cache. 363 5. Let sorted-keys be the result of running Find Available Keys 364 (Section 5.1) on sorted-variants and two empty lists. 366 This will result in a list of lists, where each member of the top- 367 level list indicates, in preference order, a key for an acceptable 368 response to the request. 370 A Cache MAY satisfy the request with any response whose Variant-Key 371 header corresponds to a member of sorted-keys; when doing so, it 372 SHOULD use the most preferred available response. 374 See also Section 2.1 regarding handling of Vary. 376 5.1. Find Available Keys 378 Given sorted-variants, a list of lists, and key-stub, a list 379 representing a partial key, and possible-keys, a list: 381 1. Let sorted-values be the first member of sorted-variants. 383 2. For each sorted-value in sorted-values: 385 1. Let this-key be a copy of key-stub. 387 2. Append sorted-value to this-key. 389 3. Let remaining-variants be a copy of all of the members of 390 sorted-variants except the first. 392 4. If remaining-variants is empty, append this-key to possible- 393 keys. 395 5. Else, run Find Available Keys on remaining-variants, this-key 396 and possible-keys. 398 6. Return possible-keys. 400 5.2. Example of Cache Behaviour 402 For example, if the selected variants-header was: 404 Variants: Accept-Language;en;fr,de, Accept-Encoding;gzip,br 406 and the request contained the headers: 408 Accept-Language: fr;q=1.0, en;q=0.1 409 Accept-Encoding: gzip 411 Then the sorted-variants would be: 413 [ 414 ["fr", "en"] // prefers French, will accept English 415 ["gzip", "identity"] // prefers gzip encoding, will accept identity 416 ] 418 Which means that the sorted-keys would be: 420 [ 421 ['fr', 'gzip'], 422 ['fr', 'identity'], 423 ['en', 'gzip'], 424 ['en', 'identity'] 425 ] 427 Representing a first preference of a French, gzip'd response. Thus, 428 if a cache has a response with: 430 Variant-Key: fr, gzip 432 it could be used to satisfy the first preference. If not, responses 433 corresponding to the other keys could be returned, or the request 434 could be forwarded towards the origin. 436 6. Example Headers 438 6.1. Single Variant 440 Given a request/response pair: 442 GET /foo HTTP/1.1 443 Host: www.example.com 444 Accept-Language: en;q=1.0, fr;q=0.5 446 HTTP/1.1 200 OK 447 Content-Type: image/gif 448 Content-Language: en 449 Cache-Control: max-age=3600 450 Variants: Content-Language;en;de 451 Variant-Key: en 452 Vary: Accept-Language 453 Transfer-Encoding: chunked 455 Upon receipt of this response, the cache knows that two 456 representations of this resource are available, one with a "Content- 457 Language" of "en", and another whose "Content-Language" is "de". 459 Subsequent requests (while this response is fresh) will cause the 460 cache to either reuse this response or forward the request, depending 461 on what the selection algorithm determines. 463 So, if a request with "en" in "Accept-Language" is received and its 464 q-value indicates that it is acceptable, the stored response is used. 465 A request that indicates that "de" is acceptable will be forwarded to 466 the origin, thereby populating the cache. A cache receiving a 467 request that indicates both languages are acceptable will use the 468 q-value to make a determination of what response to return. 470 A cache receiving a request that does not list either language as 471 acceptable (or does not contain an Accept-Language at all) will 472 return the "en" representation (possibly fetching it from the 473 origin), since it is listed first in the "Variants" list. 475 Note that "Accept-Language" is listed in Vary, to assure backwards- 476 compatibility with caches that do not support "Variants". 478 6.2. Multiple Variants 480 A more complicated request/response pair: 482 GET /bar HTTP/1.1 483 Host: www.example.net 484 Accept-Language: en;q=1.0, fr;q=0.5 485 Accept-Encoding: gzip, br 487 HTTP/1.1 200 OK 488 Content-Type: image/gif 489 Content-Language: en 490 Content-Encoding: br 491 Variants: Content-Language;en;jp;de 492 Variants: Content-Encoding;br;gzip 493 Variant-Key: en, br 494 Vary: Accept-Language, Accept-Encoding 495 Transfer-Encoding: chunked 497 Here, the cache knows that there are two axes that the response 498 varies upon; "Content-Language" and "Content-Encoding". Thus, there 499 are a total of six possible representations for the resource, and the 500 cache needs to consider the selection algorithms for both axes. 502 Upon a subsequent request, if both selection algorithms return a 503 stored representation, it can be served from cache; otherwise, the 504 request will need to be forwarded to origin. 506 6.3. Partial Coverage 508 Now, consider the previous example, but where only one of the Vary'd 509 axes is listed in "Variants": 511 GET /bar HTTP/1.1 512 Host: www.example.net 513 Accept-Language: en;q=1.0, fr;q=0.5 514 Accept-Encoding: gzip, br 516 HTTP/1.1 200 OK 517 Content-Type: image/gif 518 Content-Language: en 519 Content-Encoding: br 520 Variants: Content-Encoding;br;gzip 521 Variant-Key: br 522 Vary: Accept-Language, Accept-Encoding 523 Transfer-Encoding: chunked 525 Here, the cache will need to calculate a secondary cache key as per 526 [RFC7234], Section 4.1 - but considering only "Accept-Language" to be 527 in its field-value - and then continue processing "Variants" for the 528 set of stored responses that the algorithm described there selects. 530 7. IANA Considerations 532 This specification registers two values in the Permanent Message 533 Header Field Names registry established by [RFC3864]: 535 o Header field name: Variants 537 o Applicable protocol: http 539 o Status: standard 541 o Author/Change Controller: IETF 543 o Specification document(s): [this document] 545 o Related information: 547 o Header field name: Variant-Key 549 o Applicable protocol: http 551 o Status: standard 553 o Author/Change Controller: IETF 555 o Specification document(s): [this document] 557 o Related information: 559 8. Security Considerations 561 If the number or advertised characteristics of the representations 562 available for a resource are considered sensitive, the "Variants" 563 header by its nature will leak them. 565 Note that the "Variants" header is not a commitment to make 566 representations of a certain nature available; the runtime behaviour 567 of the server always overrides hints like "Variants". 569 9. Acknowledgments 571 This protocol is conceptually similar to, but simpler than, 572 Transparent Content Negotiation [RFC2295]. Thanks to its authors for 573 their inspiration. 575 It is also a generalisation of a Fastly VCL feature designed by 576 Rogier 'DocWilco' Mulhuijzen. 578 Thanks to Hooman Beheshti for his review and input. 580 10. References 582 10.1. Normative References 584 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 585 Requirement Levels", BCP 14, RFC 2119, 586 DOI 10.17487/RFC2119, March 1997, 587 . 589 [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", 590 BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, 591 . 593 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 594 Specifications: ABNF", STD 68, RFC 5234, 595 DOI 10.17487/RFC5234, January 2008, 596 . 598 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 599 Protocol (HTTP/1.1): Message Syntax and Routing", 600 RFC 7230, DOI 10.17487/RFC7230, June 2014, 601 . 603 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 604 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 605 DOI 10.17487/RFC7231, June 2014, 606 . 608 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 609 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 610 RFC 7234, DOI 10.17487/RFC7234, June 2014, 611 . 613 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 614 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 615 May 2017, . 617 10.2. Informative References 619 [I-D.ietf-httpbis-client-hints] 620 Grigorik, I., "HTTP Client Hints", draft-ietf-httpbis- 621 client-hints-04 (work in progress), April 2017. 623 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation 624 in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998, 625 . 627 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 628 Procedures for Message Header Fields", BCP 90, RFC 3864, 629 DOI 10.17487/RFC3864, September 2004, 630 . 632 10.3. URIs 634 [1] https://github.com/mnot/I-D/labels/variants 636 [2] https://mnot.github.io/I-D/variants/ 638 [3] https://github.com/mnot/I-D/commits/gh-pages/variants 640 [4] https://datatracker.ietf.org/doc/draft-nottingham-variants/ 642 Appendix A. Variants for Existing Content Negotiation Mechanisms 644 This appendix defines the required information to use existing 645 proactive content negotiation mechanisms (as defined in [RFC7231], 646 Section 5.3) with the "Variants" header field. 648 A.1. Accept-Encoding 650 This section defines handling for "Accept-Encoding" variants, as per 651 [RFC7231] Section 5.3.4. 653 To perform content negotiation for Accept-Encoding given an request- 654 value and available-values: 656 1. Let preferred-codings be a list of the codings in the request- 657 value, ordered by their weight, highest to lowest, as per 658 [RFC7231] Section 5.3.1 (omitting any coding with a weight of 0). 659 If "Accept-Encoding" is not present or empty, preferred-codings 660 will be empty. 662 2. If "identity" is not a member of preferred-codings, append 663 "identity". 665 3. Append "identity" to available-values. 667 4. Remove any member of available-values not present in preferred- 668 codings, comparing in a case-insensitive fashion. 670 5. Return available-values. 672 A.2. Accept-Language 674 This section defines handling for "Accept-Language" variants, as per 675 [RFC7231] Section 5.3.5. 677 To perform content negotiation for Accept-Language given an request- 678 value and available-values: 680 1. Let preferred-langs be a list of the language-ranges in the 681 request-value, ordered by their weight, highest to lowest, as per 682 [RFC7231] Section 5.3.1 (omitting any language-range with a 683 weight of 0). 685 2. If preferred-langs is empty, append "*". 687 3. Filter available-values using preferred-langs with either the 688 Basic Filtering scheme defined in [RFC4647] Section 3.3.1, or the 689 Lookup scheme defined in Section 3.4 of that document. Use the 690 first member of available-values as the default. 692 4. Return available-values. 694 Author's Address 696 Mark Nottingham 697 Fastly 699 Email: mnot@mnot.net 700 URI: https://www.mnot.net/