draft-ietf-httpbis-compression-dictionary-06.txt | draft-ietf-httpbis-compression-dictionary-latest.txt | |||
---|---|---|---|---|
HTTP Working Group P. Meenan, Ed. | HTTP Working Group P. Meenan, Ed. | |||
Internet-Draft Google LLC | Internet-Draft Google LLC | |||
Intended status: Standards Track Y. Weiss, Ed. | Intended status: Standards Track Y. Weiss, Ed. | |||
Expires: January 6, 2025 Shopify Inc | Expires: January 15, 2025 Shopify Inc | |||
July 05, 2024 | July 14, 2024 | |||
Compression Dictionary Transport | Compression Dictionary Transport | |||
draft-ietf-httpbis-compression-dictionary-06 | draft-ietf-httpbis-compression-dictionary-latest | |||
Abstract | Abstract | |||
This specification defines a mechanism for using designated HTTP | This specification defines a mechanism for using designated HTTP | |||
responses as an external dictionary for future HTTP responses for | responses as an external dictionary for future HTTP responses for | |||
compression schemes that support using external dictionaries (e.g., | compression schemes that support using external dictionaries (e.g., | |||
Brotli (RFC 7932) and Zstandard (RFC 8878)). | Brotli (RFC 7932) and Zstandard (RFC 8878)). | |||
About This Document | About This Document | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on January 6, 2025. | This Internet-Draft will expire on January 15, 2025. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 29 ¶ | skipping to change at page 2, line 29 ¶ | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | |||
2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3 | 2. Dictionary Negotiation . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Use-As-Dictionary . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.1.1. match . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1.2. match-dest . . . . . . . . . . . . . . . . . . . . . 4 | 2.1.2. match-dest . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 5 | 2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 6 | 2.2. Available-Dictionary . . . . . . . . . . . . . . . . . . 6 | |||
2.2.1. Dictionary freshness requirement . . . . . . . . . . 6 | 2.2.1. Dictionary freshness requirement . . . . . . . . . . 6 | |||
2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6 | 2.2.2. Dictionary URL matching . . . . . . . . . . . . . . . 6 | |||
2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7 | 2.2.3. Multiple matching dictionaries . . . . . . . . . . . 7 | |||
2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 7 | 2.3. Dictionary-ID . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3. The 'compression-dictionary' Link Relation Type . . . . . . . 8 | 3. The 'compression-dictionary' Link Relation Type . . . . . . . 8 | |||
4. Dictionary-Compressed Brotli . . . . . . . . . . . . . . . . 8 | 4. Dictionary-Compressed Brotli . . . . . . . . . . . . . . . . 8 | |||
5. Dictionary-Compressed Zstandard . . . . . . . . . . . . . . . 9 | 5. Dictionary-Compressed Zstandard . . . . . . . . . . . . . . . 9 | |||
skipping to change at page 3, line 11 ¶ | skipping to change at page 3, line 11 ¶ | |||
9.1. Changing content . . . . . . . . . . . . . . . . . . . . 12 | 9.1. Changing content . . . . . . . . . . . . . . . . . . . . 12 | |||
9.2. Reading content . . . . . . . . . . . . . . . . . . . . . 13 | 9.2. Reading content . . . . . . . . . . . . . . . . . . . . . 13 | |||
9.3. Security Mitigations . . . . . . . . . . . . . . . . . . 13 | 9.3. Security Mitigations . . . . . . . . . . . . . . . . . . 13 | |||
9.3.1. Cross-origin protection . . . . . . . . . . . . . . . 13 | 9.3.1. Cross-origin protection . . . . . . . . . . . . . . . 13 | |||
9.3.2. Response readability . . . . . . . . . . . . . . . . 13 | 9.3.2. Response readability . . . . . . . . . . . . . . . . 13 | |||
9.3.3. Server Responsibility . . . . . . . . . . . . . . . . 14 | 9.3.3. Server Responsibility . . . . . . . . . . . . . . . . 14 | |||
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 | 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 16 | 11.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
1. Introduction | 1. Introduction | |||
This specification defines a mechanism for using designated [HTTP] | This specification defines a mechanism for using designated [HTTP] | |||
responses as an external dictionary for future HTTP responses for | responses as an external dictionary for future HTTP responses for | |||
compression schemes that support using external dictionaries (e.g., | compression schemes that support using external dictionaries (e.g., | |||
Brotli [RFC7932] and Zstandard [RFC8878]). | Brotli [RFC7932] and Zstandard [RFC8878]). | |||
This document describes the HTTP headers used for negotiating | This document describes the HTTP headers used for negotiating | |||
dictionary usage and registers media types for content encoding | dictionary usage and registers media types for content encoding | |||
skipping to change at page 3, line 36 ¶ | skipping to change at page 3, line 36 ¶ | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
This document uses the following terminology from Section 3 of | This document uses the following terminology from Section 3 of | |||
[STRUCTURED-FIELDS] to specify syntax and parsing: Dictionary, | [STRUCTURED-FIELDS] to specify syntax and parsing: Dictionary, | |||
String, Inner List, Token, and Byte Sequence. | String, Inner List, Token, and Byte Sequence. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
document are to be interpreted as described in [RFC2119]. | ||||
This document uses the line folding strategies described in | This document uses the line folding strategies described in | |||
[FOLDING]. | [FOLDING]. | |||
This document also uses terminology from [HTTP] and [HTTP-CACHING]. | This document also uses terminology from [HTTP] and [HTTP-CACHING]. | |||
2. Dictionary Negotiation | 2. Dictionary Negotiation | |||
2.1. Use-As-Dictionary | 2.1. Use-As-Dictionary | |||
When responding to a HTTP Request, a server can advertise that the | When responding to a HTTP Request, a server can advertise that the | |||
skipping to change at page 4, line 40 ¶ | skipping to change at page 4, line 38 ¶ | |||
4. If PATTERN has regexp groups then return FALSE. | 4. If PATTERN has regexp groups then return FALSE. | |||
5. Return True. | 5. Return True. | |||
The "match" value is required and MUST be included in the Use-As- | The "match" value is required and MUST be included in the Use-As- | |||
Dictionary Dictionary for the dictionary to be considered valid. | Dictionary Dictionary for the dictionary to be considered valid. | |||
2.1.2. match-dest | 2.1.2. match-dest | |||
The "match-dest" value of the Use-As-Dictionary header is an Inner | The "match-dest" value of the Use-As-Dictionary header is an Inner | |||
List of String values that provides a list of request destinations | List of String values that provides a list of [FETCH] request | |||
for the dictionary to match (https://fetch.spec.whatwg.org/#concept- | destinations for the dictionary to match. | |||
request-destination). | ||||
An empty list for "match-dest" MUST match all destinations. | An empty list for "match-dest" MUST match all destinations. | |||
For clients that do not support request destinations, the client MUST | For clients that do not support request destinations, the client MUST | |||
treat it as an empty list and match all destinations. | treat it as an empty list and match all destinations. | |||
The "match-dest" value is optional and defaults to an empty list. | The "match-dest" value is optional and defaults to an empty list. | |||
2.1.3. id | 2.1.3. id | |||
skipping to change at page 5, line 50 ¶ | skipping to change at page 5, line 44 ¶ | |||
2.1.5.1. Path Prefix | 2.1.5.1. Path Prefix | |||
A response that contained a response header: | A response that contained a response header: | |||
NOTE: '\' line wrapping per RFC 8792 | NOTE: '\' line wrapping per RFC 8792 | |||
Use-As-Dictionary: \ | Use-As-Dictionary: \ | |||
match="/product/*", match-dest=("document") | match="/product/*", match-dest=("document") | |||
Would specify matching any document request for a URL with a path | Would specify matching any document request for a URL with a path | |||
prefix of /product/ on the same [Origin] as the original request. | prefix of /product/ on the same Origin [RFC6454] as the original | |||
request. | ||||
2.1.5.2. Versioned Directories | 2.1.5.2. Versioned Directories | |||
A response that contained a response header: | A response that contained a response header: | |||
Use-As-Dictionary: match="/app/*/main.js" | Use-As-Dictionary: match="/app/*/main.js" | |||
Would match main.js in any directory under /app/ and expiring as a | Would match main.js in any directory under /app/ and expiring as a | |||
dictionary in one year. | dictionary in one year. | |||
skipping to change at page 6, line 46 ¶ | skipping to change at page 6, line 46 ¶ | |||
fresh [HTTP-CACHING] or allowed to be served stale (see eg | fresh [HTTP-CACHING] or allowed to be served stale (see eg | |||
[RFC5861]). | [RFC5861]). | |||
2.2.2. Dictionary URL matching | 2.2.2. Dictionary URL matching | |||
When a dictionary is stored as a result of a "Use-As-Dictionary" | When a dictionary is stored as a result of a "Use-As-Dictionary" | |||
directive, it includes "match" and "match-dest" strings that are used | directive, it includes "match" and "match-dest" strings that are used | |||
to match an outgoing request from a client to the available | to match an outgoing request from a client to the available | |||
dictionaries. | dictionaries. | |||
Dictionaries MUST have been served from the same {Origin} as the | Dictionaries MUST have been served from the same Origin [RFC6454] as | |||
outgoing request to match. | the outgoing request to match. | |||
To see if an outbound request matches a given dictionary, the | To see if an outbound request matches a given dictionary, the | |||
following algorithm will return TRUE for a successful match and FALSE | following algorithm will return TRUE for a successful match and FALSE | |||
for no-match: | for no-match: | |||
1. If the current client supports request destinations: | 1. If the current client supports request destinations: | |||
* Let DEST be the value of "match-dest" for the given | * Let DEST be the value of "match-dest" for the given | |||
dictionary. | dictionary. | |||
* Let REQUEST_DEST be the value of the destination for the | * Let REQUEST_DEST be the value of the destination for the | |||
current request. | current request. | |||
* If DEST is not an empty list and if REQUEST_DEST is not in the | * If DEST is not an empty list and if REQUEST_DEST is not in the | |||
DEST list of destinations, return FALSE | DEST list of destinations, return FALSE | |||
2. Let BASEURL be the URL of the dictionary request. | 2. Let BASEURL be the URL of the dictionary request. | |||
3. Let URL represent the URL of the outbound request being checked. | 3. Let URL represent the URL of the outbound request being checked. | |||
4. If the {Origin} of BASEURL and the {Origin} of URL are not the | 4. If the Origin of BASEURL and the Origin of URL are not the same, | |||
same, return FALSE. | return FALSE. | |||
5. Let MATCH be the value of "match" for the given dictionary. | 5. Let MATCH be the value of "match" for the given dictionary. | |||
6. Let PATTERN be a URL Pattern [URLPattern] constructed by setting | 6. Let PATTERN be a URL Pattern [URLPattern] constructed by setting | |||
input=MATCH, and baseURL=BASEURL. | input=MATCH, and baseURL=BASEURL. | |||
7. Return the result of running the "test" method of PATTERN with | 7. Return the result of running the "test" method of PATTERN with | |||
input=URL. | input=URL. | |||
2.2.3. Multiple matching dictionaries | 2.2.3. Multiple matching dictionaries | |||
skipping to change at page 13, line 9 ¶ | skipping to change at page 13, line 9 ¶ | |||
explicitly needed to counter attacks since the dictionary is being | explicitly needed to counter attacks since the dictionary is being | |||
served from the same origin as the content. That said, if a weakness | served from the same origin as the content. That said, if a weakness | |||
is discovered in SHA-256 and it is determined that the dictionary | is discovered in SHA-256 and it is determined that the dictionary | |||
negotiation should use a different hash algorithm, the "Use-As- | negotiation should use a different hash algorithm, the "Use-As- | |||
Dictionary" response header can be extended to specify a different | Dictionary" response header can be extended to specify a different | |||
algorithm and the server would just ignore any "Available-Dictionary" | algorithm and the server would just ignore any "Available-Dictionary" | |||
requests that do not use the updated hash. | requests that do not use the updated hash. | |||
9.2. Reading content | 9.2. Reading content | |||
The CRIME attack shows that it's a bad idea to compress data from | The compression attacks in Section 2.6 of [RFC7457] show that it's a | |||
mixed (e.g. public and private) sources -- the data sources include | bad idea to compress data from mixed (e.g. public and private) | |||
not only the compressed data but also the dictionaries. For example, | sources -- the data sources include not only the compressed data but | |||
if you compress secret cookies using a public-data-only dictionary, | also the dictionaries. For example, if you compress secret cookies | |||
you still leak information about the cookies. | using a public-data-only dictionary, you still leak information about | |||
the cookies. | ||||
Not only can the dictionary reveal information about the compressed | Not only can the dictionary reveal information about the compressed | |||
data, but vice versa, data compressed with the dictionary can reveal | data, but vice versa, data compressed with the dictionary can reveal | |||
the contents of the dictionary when an adversary can control parts of | the contents of the dictionary when an adversary can control parts of | |||
data to compress and see the compressed size. On the other hand, if | data to compress and see the compressed size. On the other hand, if | |||
the adversary can control the dictionary, the adversary can learn | the adversary can control the dictionary, the adversary can learn | |||
information about the compressed data. | information about the compressed data. | |||
9.3. Security Mitigations | 9.3. Security Mitigations | |||
skipping to change at page 13, line 48 ¶ | skipping to change at page 13, line 49 ¶ | |||
tracking, additional protections MUST be taken to make sure that the | tracking, additional protections MUST be taken to make sure that the | |||
use of dictionary-based compression does not reveal information that | use of dictionary-based compression does not reveal information that | |||
would not otherwise be available. | would not otherwise be available. | |||
In these cases, dictionary compression MUST only be used when both | In these cases, dictionary compression MUST only be used when both | |||
the dictionary and the compressed response are fully readable by the | the dictionary and the compressed response are fully readable by the | |||
client. | client. | |||
In browser terms, that means that both are either same-origin to the | In browser terms, that means that both are either same-origin to the | |||
context they are being fetched from or that the response is cross- | context they are being fetched from or that the response is cross- | |||
origin and passes the CORS check | origin and passes the CORS check as defined in [FETCH]. | |||
(https://fetch.spec.whatwg.org/#cors-check). | ||||
9.3.3. Server Responsibility | 9.3.3. Server Responsibility | |||
As with any usage of compressed content in a secure context, a | As with any usage of compressed content in a secure context, a | |||
potential timing attack exists if the attacker can control any part | potential timing attack exists if the attacker can control any part | |||
of the dictionary, or if it can read the dictionary and control any | of the dictionary, or if it can read the dictionary and control any | |||
part of the content being compressed, while performing multiple | part of the content being compressed, while performing multiple | |||
requests that vary the dictionary or injected content. Under such an | requests that vary the dictionary or injected content. Under such an | |||
attack, the changing size or processing time of the response reveals | attack, the changing size or processing time of the response reveals | |||
information about the content, which might be sufficient to read the | information about the content, which might be sufficient to read the | |||
skipping to change at page 15, line 18 ¶ | skipping to change at page 15, line 18 ¶ | |||
6. return FALSE. | 6. return FALSE. | |||
10. Privacy Considerations | 10. Privacy Considerations | |||
Since dictionaries are advertised in future requests using the hash | Since dictionaries are advertised in future requests using the hash | |||
of the content of the dictionary, it is possible to abuse the | of the content of the dictionary, it is possible to abuse the | |||
dictionary to turn it into a tracking cookie. | dictionary to turn it into a tracking cookie. | |||
To mitigate any additional tracking concerns, clients MUST treat | To mitigate any additional tracking concerns, clients MUST treat | |||
dictionaries in the same way that they treat cookies. This includes | dictionaries in the same way that they treat cookies [RFC6265]. This | |||
partitioning the storage as cookies are partitioned as well as | includes partitioning the storage as cookies are partitioned as well | |||
clearing the dictionaries whenever cookies are cleared. | as clearing the dictionaries whenever cookies are cleared. | |||
11. References | 11. References | |||
11.1. Normative References | 11.1. Normative References | |||
[FETCH] WHATWG, "Fetch - Living Standard", June 2024, | ||||
<https://fetch.spec.whatwg.org>. | ||||
[FOLDING] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, | [FOLDING] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, | |||
"Handling Long Lines in Content of Internet-Drafts and | "Handling Long Lines in Content of Internet-Drafts and | |||
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, | RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, | |||
<https://www.rfc-editor.org/info/rfc8792>. | <https://www.rfc-editor.org/info/rfc8792>. | |||
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP Semantics", STD 97, RFC 9110, | Ed., "HTTP Semantics", STD 97, RFC 9110, | |||
DOI 10.17487/RFC9110, June 2022, | DOI 10.17487/RFC9110, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9110>. | <https://www.rfc-editor.org/info/rfc9110>. | |||
skipping to change at page 15, line 47 ¶ | skipping to change at page 15, line 50 ¶ | |||
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP Caching", STD 98, RFC 9111, | Ed., "HTTP Caching", STD 98, RFC 9111, | |||
DOI 10.17487/RFC9111, June 2022, | DOI 10.17487/RFC9111, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9111>. | <https://www.rfc-editor.org/info/rfc9111>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale | ||||
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, | ||||
<https://www.rfc-editor.org/info/rfc5861>. | ||||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | [SHA-256] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms | |||
(SHA and SHA-based HMAC and HKDF)", RFC 6234, | (SHA and SHA-based HMAC and HKDF)", RFC 6234, | |||
DOI 10.17487/RFC6234, May 2011, | DOI 10.17487/RFC6234, May 2011, | |||
<https://www.rfc-editor.org/info/rfc6234>. | <https://www.rfc-editor.org/info/rfc6234>. | |||
[STRUCTURED-FIELDS] | ||||
"Structured Field Values for HTTP", May 2024, | ||||
<https://datatracker.ietf.org/doc/draft-ietf-httpbis- | ||||
sfbis/>. | ||||
[URLPattern] | [URLPattern] | |||
"URL Pattern Standard", March 2024, | WHATWG, "URL Pattern - Living Standard", March 2024, | |||
<https://urlpattern.spec.whatwg.org/>. | <https://urlpattern.spec.whatwg.org/>. | |||
[WEB-LINKING] | [WEB-LINKING] | |||
Nottingham, M., "Web Linking", RFC 8288, | Nottingham, M., "Web Linking", RFC 8288, | |||
DOI 10.17487/RFC8288, October 2017, | DOI 10.17487/RFC8288, October 2017, | |||
<https://www.rfc-editor.org/info/rfc8288>. | <https://www.rfc-editor.org/info/rfc8288>. | |||
11.2. Informative References | 11.2. Informative References | |||
[Origin] Barth, A., "The Web Origin Concept", RFC 6454, | [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale | |||
Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, | ||||
<https://www.rfc-editor.org/info/rfc5861>. | ||||
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, | ||||
DOI 10.17487/RFC6265, April 2011, | ||||
<https://www.rfc-editor.org/info/rfc6265>. | ||||
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, | ||||
DOI 10.17487/RFC6454, December 2011, | DOI 10.17487/RFC6454, December 2011, | |||
<https://www.rfc-editor.org/info/rfc6454>. | <https://www.rfc-editor.org/info/rfc6454>. | |||
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing | ||||
Known Attacks on Transport Layer Security (TLS) and | ||||
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, | ||||
February 2015, <https://www.rfc-editor.org/info/rfc7457>. | ||||
[RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data | [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data | |||
Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, | Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, | |||
<https://www.rfc-editor.org/info/rfc7932>. | <https://www.rfc-editor.org/info/rfc7932>. | |||
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu, | ||||
"Handling Long Lines in Content of Internet-Drafts and | ||||
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020, | ||||
<https://www.rfc-editor.org/info/rfc8792>. | ||||
[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression | [RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression | |||
and the 'application/zstd' Media Type", RFC 8878, | and the 'application/zstd' Media Type", RFC 8878, | |||
DOI 10.17487/RFC8878, February 2021, | DOI 10.17487/RFC8878, February 2021, | |||
<https://www.rfc-editor.org/info/rfc8878>. | <https://www.rfc-editor.org/info/rfc8878>. | |||
[SHARED-BROTLI] | [SHARED-BROTLI] | |||
"Shared Brotli Compressed Data Format", September 2022, | "Shared Brotli Compressed Data Format", September 2022, | |||
<https://datatracker.ietf.org/doc/draft-vandevenne-shared- | <https://datatracker.ietf.org/doc/draft-vandevenne-shared- | |||
brotli-format/>. | brotli-format/>. | |||
[STRUCTURED-FIELDS] | ||||
Nottingham, M. and P. Kamp, "Structured Field Values for | ||||
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, | ||||
<https://www.rfc-editor.org/info/rfc8941>. | ||||
Authors' Addresses | Authors' Addresses | |||
Patrick Meenan (editor) | Patrick Meenan (editor) | |||
Google LLC | Google LLC | |||
Email: pmeenan@google.com | Email: pmeenan@google.com | |||
Yoav Weiss (editor) | Yoav Weiss (editor) | |||
Shopify Inc | Shopify Inc | |||
Email: yoav.weiss@shopify.com | Email: yoav.weiss@shopify.com | |||
End of changes. 22 change blocks. | ||||
39 lines changed or deleted | 53 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |