privacycg / storage-access-headers

Proposal for HTTP headers related to the Storage Access API
https://cfredric.github.io/storage-access-headers/
Creative Commons Attribution 4.0 International
27 stars 2 forks source link

Clarify: why is `load` required in addition to `retry`? #16

Closed drmercer-lucid closed 2 months ago

drmercer-lucid commented 2 months ago

I read the example for iframed content, and I don't think I understand why the server has to respond with Activate-Storage-Access: load to the second request. It says this:

The response includes a Activate-Storage-Access: load header, to indicate that the user agent should load the content with the storage-access permission activated (i.e. load with unpartitioned cookie access, as if document.requestStorageAccess() had been called).

But doesn't the Activate-Storage-Access: retry header already activate the storage-access permission for that frame? The steps just prior say this (emphasis added):

The server responds with a Activate-Storage-Access: retry; allowed-origin=<origin> header, to indicate that the resource fetch requires the use of unpartitioned cookies via the storage-access permission. The user agent retries the request, this time including unpartitioned cookies (activating the storage-access permission for this fetch).

Put another way, why does Activate-Storage-Access: retry behave differently than roughly this JavaScript?

await document.requestStorageAccess();
window.location.reload();
cfredric commented 2 months ago

The retry response header is for when the content of the response itself requires some authentication; i.e., the server cannot serve the request unless the client provides an authentication cookie to prove that it should have access to that resource. (This could be useful for iframes, or any other resource, but it's most useful for things like images/media which cannot run JavaScript.)

(If the resource happens to be an iframe that can run JavaScript, then you can achieve this using the JS code you wrote, too. That code just incurs performance overhead from fetching and loading the iframe (and some/all of its subresources) twice, instead of fetching twice and loading once.)


The load response header is an optimization intended for iframes, which is functionally equivalent to executing the JS you wrote in the iframe. The benefit is performance, since the iframe (and some/all of its subresources) is only fetched and loaded once.


The fact that the load and retry headers exist separately means that you have a little more flexibility and can be specific about the behavior you want.

drmercer-lucid commented 2 months ago

I think that makes sense. Does that mean you can use retry (on the first response) without also using load (on the second)? When I read the iframe example, it seems to imply you need both.

cfredric commented 2 months ago

Does that mean you can use retry (on the first response) without also using load (on the second)?

Yup, that's possible. The "non-iframe" example uses retry without using load, for example.

cfredric commented 2 months ago

I'm going to tentatively close this issue since I believe I've answered your questions; feel free to reopen or open new issues as you continue to evaluate this proposal.