Writing to Shared Storage via response headers

[fcurti]

As described here https://github.com/WICG/shared-storage#writing-to-shared-storage-via-response-headers
I'm trying to set shared storage using via response headers.

var x = new XMLHttpRequest();
x.setRequestHeader("sharedStorageWritable", "true");
and so on...

The origin send Sharedstoragewritable in the request header with value true
The response header contains the Shared-Storage-Write but nothing is written into origin shared storage.

I do not see the Sec-Shared-Storage-Writable in the request header as I would expected.

I did a test also on same domain to avoid any permissions checks issues.

[pythagoraskitty]

Hello and thanks so much for testing this new feature!

You'll need to use fetch() instead of new XMLHttpRequest(). We didn't implement support for XHR.

For example:

fetch("https://a.example/path/for/updates", {sharedStorageWritable: true}).then((response) => {
  // do something
});

[fcurti]

Thank you @pythagoraskitty

[zsoltbalintmindit]

Hello @pythagoraskitty . I'm trying out this feature, but unfortunately it seams to not working for me. In my setup I'm using chrome version: 120.0.6099.71, and for testing purpose an express server to set corresponding headers into response. What i'm missing from the request header is the optin part: Sec-Shared-Storage-Writable: ?1. Should this be set and visible on the request mabe by the fetch, am i right? Thx.

[pythagoraskitty]

Yes, when the server receives the request, it should have the request header "Sec-Shared-Storage-Writable: ?1", if opted in correctly and with permissions that allow it, and if shared storage is enabled (it should be enabled by default).

Can you please tell me how you are making the request?

Have you double-checked that your permissions policy allows shared storage for the origin of the request?

Also, how are you checking for the request header? JavaScript on the client will not be able to see it because it's a forbidden header; only the server should be able to see it. Have you confirmed that the server cannot see it?

Any further details you can give me to assist you in debugging would be appreciated. Thank you.

[zsoltbalintmindit]

Thank you for your response. How should i check that permission policy is allowed ? Do you mean that when the page is send back should i put it on the response headers like this: res.set('Permissions-Policy', 'storage-access=*');

This is the sample express endpoint which I'm using:

app.get("/set-headers", (req, res) => { res.set('Shared-Storage-Write', 'clear,set;key="hello";value="world";ignore_if_present, append;key="good";value="bye", delete;key="hello", set;key="all";value="done"'); res.json({ message: "Data from the server" }); });

And this is the request which I made :

fetch( https://${contentProducerUrl}/set-headers, { sharedStorageWritable: true })

I'm checking in dev-tools to see if on the request the "Sec-Shared-Storage-Writable" is present, should be this visible there? On the server also the header is not visible.

Thank you.

[pythagoraskitty]

Is your fetch() request made as a first-party or a third-party? Are you trying to make it from a window or a service worker? (Currently we only support requests initiated from windows.)

It's possible that res.set('Permissions-Policy', 'shared-storage=*'); (or else with the necessary origin instead of *) may help, but what really matters permission-wise is the inherited permissions policy for the frame making the request, not the permissions policy for the fetch request itself. Are you making the request from the main frame or an iframe? And are you using the default permissions policy, or has it been set?

You can check permissions policy through:
const allowed = document.featurePolicy.allowsFeature('shared-storage', document.location.origin); .

The "Sec-Shared-Storage-Writable" request header will only be added if the request opts in (e.g. by including
{ sharedStorageWritable: true } as a parameter in the fetch request), the permissions policy allows it, and the end user has shared storage enabled.

I believe that the "Sec-Shared-Storage-Writable" request header should be visible to DevTools if it has been added. It definitely should be visible to the server. So it sounds like in your case it's not being added, which means there is most likely a permissions policy issue, or else you're trying to make the fetch request from a service worker (where shared storage response headers aren't supported). Or there is a chance that your browser doesn't have shared storage enabled, so you should double check that.

[pythagoraskitty]

Unfortunately the response headers did not ship by default as intended with 119 due to a bug in enabling them by default.

They are now enabled by default in 124, but have to be manually enabled via command line in milestones 119 to 123. If you are still running into issues with testing them, then please use Chrome 124+ or else Chrome 119+ with --enable-features=SharedStorageAPIM118 on the command line.

Let us know if you run into further trouble while testing after making these adjustments. Thank you.

[zsoltbalintmindit]

Hello @pythagoraskitty and thanks for your suggestions. I tried in this morning with Chrome 123 with that feature flag enabled, and it is not working, but with version 124 from Chrome Dev, shared storage keys are set based on headers values.

[pythagoraskitty]

Here is a demo that may help with troubleshooting for 123 with the feature enabled.

In particular, for your test setup, are you overriding the attestation requirement, or is the site you are testing already attested?

If you are overriding the attestation, you may find that, by launching from the command line, you need to update your overrides again, and this may be why the headers are failing (i.e. the site is seen as not attested).

Does DevTools console give you any error message when trying to send the headers?