Skip to content
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

Ability to clear specific Storage Buckets via Clear-Site-Data #61

Open
asutherland opened this issue Sep 18, 2019 · 1 comment
Open

Comments

@asutherland
Copy link

asutherland commented Sep 18, 2019

We're working towards adding multiple storage buckets per origin at whatwg/storage#2. The idea behind storage buckets are that they constitute separate groups of atomically evictable storage. So, sub-partitions of the current "storage" type. Each bucket would have a name that is not displayed to the user (there is a separate "title" for that). The name could be constrained to only ASCII values.

It's not immediately clear what the syntax would be for the HTTP header to identify a specific storage bucket for clearing. Reading https://w3c.github.io/webappsec-clear-site-data/#header and https://w3c.github.io/webappsec-clear-site-data/#parsing there is no prior art in the spec. https://httpwg.org/http-extensions/draft-ietf-httpbis-header-structure.html#list suggests inner lists might work? So Clear-Site-Data: ("storage" "bucket1"), "cookies" would clear bucket1 and cookies. The other alternative would seem to be using a prefix within the existing string list, so Clear-Site-Data: "storage:bucket1", "cookies" would accomplish the same thing.

What would be the right course of action to evolve Clear-Site-Data to support buckets as they move forward with standardization?

@annevk
Copy link
Member

annevk commented Sep 20, 2019

(One way to go here might be to make the Storage Standard own this header as well so they can evolve together more easily.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants