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
At the moment, Sec-Fetch-User is defined as being sent for navigation requests only. Following on to the conversation in #23, it might be useful to specify how Sec-Fetch-User could work for some categories of subresource requests.
@arturjanc: This seems like something we can come back to after y'all finish deploying things more generally for navigation requests. How would you rate its priority?
The text was updated successfully, but these errors were encountered:
I don't expect this to be a particularly common use of Sec-Fetch headers. For subresource requests the signal that developers are more likely use is the site value: if they trust the source (e.g. it's a same-origin request) they will return a response, and if they don't (e.g. it's a cross-site request) then it doesn't particularly matter whether there was a user action associated with the request. It could be a way to rate-limit, similarly to how developers could allow only those navigations that resulted from a user action, but my guess is it would be a niche use case.
At the moment,
Sec-Fetch-User
is defined as being sent for navigation requests only. Following on to the conversation in #23, it might be useful to specify howSec-Fetch-User
could work for some categories of subresource requests.@arturjanc: This seems like something we can come back to after y'all finish deploying things more generally for navigation requests. How would you rate its priority?
The text was updated successfully, but these errors were encountered: