-
Notifications
You must be signed in to change notification settings - Fork 373
Add support for compression dictionary transport #1854
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The RFC is pending publication so this will have to wait until that happens (should be any day now). RFC number has been assigned and final edits are complete: https://www.rfc-editor.org/auth48/rfc9842 |
8decfba to
e089eab
Compare
e089eab to
8bc5398
Compare
|
RFC has published now so this should be ready to go (just rebased it). |
|
From the TPAC 2025 discussions, I added support for opaque responses to use compression dictionary when the |
| "HTTP-COMPRESSION-DICTIONARIES": { | ||
| "aliasOf": "RFC9842" | ||
| }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can just reference the RFC number directly. No need for an alias.
| <p>A <a for=/>request</a> has an associated | ||
| <dfn export for=request id=concept-request-initiator>initiator</dfn>, which is | ||
| the empty string, | ||
| "<code>compression-dictionary</code>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need a distinct initiator if we also have a distinct destination?
|
|
||
| <li><p>If <var>key</var> is null, then return null. | ||
|
|
||
| <li><p>Return the unique compression-dictionary cache associated with <var>key</var>. [[!HTTP-COMPRESSION-DICTIONARIES]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there PRs against Storage and Clear-Site-Data about clearing this cache? It would be good if those were linked from the commit message.
|
|
||
| <li> | ||
| <p>If <var>response</var>'s <a for=response>header list</a> | ||
| <a for="header list">contains</a> `<code>Use-As-Dictionary</code>`, then: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| <a for="header list">contains</a> `<code>Use-As-Dictionary</code>`, then: | |
| <a for="header list">contains</a> `<code>Use-As-Dictionary</code>`: |
| <li><p>If <var>dictionaryValue</var> is null or <var>dictionaryValue</var>["<code>match</code>"] | ||
| does not <a for=map>exist</a>, then return <var>response</var>. | ||
|
|
||
| <li><p>Let <var>pattern</var> be the result of creating a URL pattern from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"creating a URL pattern" needs some kind of link to a definition.
| <li><p>Let <var>corpPolicy</var> be the result of <a for="header list">getting</a> | ||
| `<a http-header><code>Cross-Origin-Resource-Policy</code></a>` from <var>response</var>'s | ||
| <a for=response>header list</a>. | ||
|
|
||
| <li><p>If <var>request</var>'s <a for=request>response tainting</a> is "<code>opaque</code>" and | ||
| <var>corpPolicy</var> is not `<code>cross-origin</code>`, then return <var>response</var>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't good enough. We want corpPolicy to be a good value across redirects. We should have tests for that as well.
| <li><p>If <var>request</var>'s <a for=request>response tainting</a> is "<code>opaque</code>" and | ||
| <var>corpPolicy</var> is not `<code>cross-origin</code>`, then return <var>response</var>. | ||
|
|
||
| <li><p>Let <var>expirationTime</var> be the time at which the <var>response</var> becomes stale. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs more links to definitions.
| <li><p>If <var>expirationTime</var> is not in the future, then return <var>response</var>. | ||
|
|
||
| <li><p>Store <var>response</var> in <var>compressionDictionaryCache</var> with its associated | ||
| <var>dictionaryValue</var> and <var>expirationTime</var>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we also store pattern somewhere?
| <li><p>If the user agent is configured to block cookies for <var>request</var>, then return the | ||
| result of running <a>HTTP-network fetch</a> given <var>fetchParams</var>, | ||
| <var>includeCredentials</var>, and <var>forceNewConnection</var>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this. The dictionary is partitioned so how is it different from the HTTP cache?
| <li><p><a for="header list">Combine</a> (`<code>Accept-Encoding</code>`, `<code>dcb</code>`) | ||
| in <var>request</var>'s <a for=request>header list</a>. | ||
|
|
||
| <li><p><a for="header list">Combine</a> (`<code>Accept-Encoding</code>`, `<code>dcz</code>`) | ||
| in <var>request</var>'s <a for=request>header list</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we doing this even if web developers set these headers? That seems rather sketchy.
Add processing steps for handling HTTP Compression Dictionary Transport content encoding and dictionary negotiation (RFC pending publication).
This adds a processing layer between the HTTP cache and network fetch that handles most of the dictionary-based content encoding (including matching dictionaries to outgoing requests).
Additionally, it adds processing above the HTTP cache for storing the dictionaries for future use and defines the "compression-dictionary" initiator and destination (the matching HTML spec update is in-process).
Fix #1739, #1839
Preview | Diff