Re: [w3ctag/design-reviews] Question: Using Cross-Origin-Resource-Policy to enable compression dictionary support for opaque responses (Issue #1203)

yoavweiss left a comment (w3ctag/design-reviews#1203)

FWIW, I think the approach is extremely reasonable and the semantics you're after align really well with `CORP: cross-origin`



> This approach should be web-safe to add but it does depend on origins making sure that they include the CORP header for responses to cross-origin requests when they use dictionary compression (if the dictionary was cors-fetched but the resource was no-cors fetched). If existing origins are blindly dictionary-compressing every request that advertises an `Available-Dictionary` then those resources will start to fail in a cross-origin no-cors context if they don't include the CORP header (the RFC already warns that they should not be doing this).

This seems mostly risky in the case of a dictionary that's set to a wide path range (e.g. a [separate dictionary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport#separate_dictionary) that covers large portion of the site). As such, it's less applicable to the [existing resource](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Compression_dictionary_transport#existing_resource_as_a_dictionary) case.

So IIUC, this is likely only an issue with cross-origin resources compressed by a separate dictionary, which I'd expect to be relatively rare. Does that match your understanding?


*If* deploying this hits hurdles due to deployments we're not aware of, it seems like we could at that point add an opt-in signal (to `Use-As-Dictionary` or to `<link rel=compression-dictionary>`).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1203#issuecomment-4070740678
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1203/4070740678@github.com>