Add support for compression dictionary transport#1854
Add support for compression dictionary transport#1854pmeenan wants to merge 10 commits intowhatwg:mainfrom
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 |
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 |
fetch.bs
Outdated
|
|
||
| <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.
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.
fetch.bs
Outdated
| <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.
"creating a URL pattern" needs some kind of link to a definition.
There was a problem hiding this comment.
Added (let me know if the reference to the urlpattern spec should be handled differently - I tried to mimick what was used for resource timing.
fetch.bs
Outdated
| <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.
This isn't good enough. We want corpPolicy to be a good value across redirects. We should have tests for that as well.
There was a problem hiding this comment.
I don't know if something more generic would make sense but my current plan is:
- Add a
compression dictionary blockedflag to request that starts out as unset - In main fetch, each time the response is processed and after
response taintinghas been updated and is currentlyopaque, check the corp header. - If the header is missing or not set to
cross-originthen set thecompression dictionary blockedflag - Replace the check here with a check of the
compression dictionary blockedflag
I don't know if the same CORP readability logic could or should be used for anything else and a more generic tainting name should be used.
There was a problem hiding this comment.
I went ahead and added a compression dictionary disallowed flag to request which is updated in Main fetch just after the response tainting is evaluated for each step and then the flag is just checked when doing dictionary-specific work (ignoring the Use-As-Dictionary header and erroring dictionary-compressed opaque responses.
fetch.bs
Outdated
| <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.
This needs more links to definitions.
There was a problem hiding this comment.
Added a link to the stale response definition.
| <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.
I don't understand this. The dictionary is partitioned so how is it different from the HTTP cache?
There was a problem hiding this comment.
The Use-As-Dictionary response header can attach an arbitrary ID to arbitrary requests from the same origin (that match a given pattern) without having to access the underlying response. This allows non-executable responses to attach a tracking ID to an origin that behaves like a cookie without having to execute code (image-only origins for example).
To keep things consistent with dev expectations and CSP, the security and privacy teams requested that they also be treated as cookies and not be allowed in situations where cookies would not have been allowed.
| <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.
Are we doing this even if web developers set these headers? That seems rather sketchy.
There was a problem hiding this comment.
Accept-Encoding is a forbidden request header so developers shouldn't be able to set it.
defe29f to
e8ce404
Compare
e8ce404 to
b0403bd
Compare
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