You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The wildcard is a little weird for an origin, and it's not a parseable URL. We would have to specialize the parser for it.
{
"id": "/",
"name": "Example",
"display": "standalone",
"start_url": "/index.html",
"scope_extensions": [
{"origin": "https://example.com", "treat_as_registrable_domain": true },
// but this could also parse OK too:
{"origin": "https://www.example.com", "treat_as_registrable_domain": true },
{"origin": "https://www.example.co.uk"},
]
}
This would allow only the www.example.co.uk part of example.co.uk, but allow ANY subdomain of example.com, as we treat the origin as a registrable domain.
Also, the spec already has a definition of registrable domain / eTLD+1, so we can parse that correctly. And we should likely require inclusion the https of the origin.
The text was updated successfully, but these errors were encountered:
I'm in favour of this change. We should stick with standard URL parsing if possible as there are likely edge cases this simplified form fails to handle.
The wildcard is a little weird for an origin, and it's not a parseable URL. We would have to specialize the parser for it.
This would allow only the
www.example.co.uk
part of example.co.uk, but allow ANY subdomain of example.com, as we treat the origin as a registrable domain.Also, the spec already has a definition of registrable domain / eTLD+1, so we can parse that correctly. And we should likely require inclusion the https of the origin.
The text was updated successfully, but these errors were encountered: