Open johnivdel opened 2 years ago
One downside to combining the headers is that we expect users to manually set Attribution-Reporting-Eligible
on fetch
-based requests in order to support event-source
registrations, but it is the browser that determines the os
and web
values. It may complicate the implementation for the browser to have to validate and/or modify the user-specified header to accurately reflect os
and web
.
I agree with @apasel422 that it seems really problematic to modify a user set header.
One downside to combining the headers is that we expect users to manually set
Attribution-Reporting-Eligible
onfetch
-based requests in order to supportevent-source
registrations, but it is the browser that determines theos
andweb
values. It may complicate the implementation for the browser to have to validate and/or modify the user-specified header to accurately reflectos
andweb
.
I do wonder if this speaks to a problem in the API design where we configure the API using request headers instead of explicit params to fetch
/ xhr
.
The API now supports explicit parameters on fetch/xhr, so the concern raised above is less problematic.
The compat risk here is low.
Given that the Attribution-Reporting-Eligible is a structured header, and has "GREASE" parameters, it would be straightforward to add new parameters in a backwards compatible way for OS-Support.
Given the fetch/xhr changes, it seems worthwhile to re-use the eligibility header just for simplicity in the Cross app and web API.
Given that the Attribution-Reporting-Eligible is a structured header, and has "GREASE" parameters, it would be straightforward to add new parameters in a backwards compatible way for OS-Support.
+1 to this. Where we send this today:
Attribution-Reporting-Eligible: event-source, trigger
Attribution-Reporting-Support: web, os
we could instead send
Attribution-Reporting-Eligible: event-source, trigger, registrar=(web os)
Currently, the app_to_web explainer proposes adding a new request header which specifies whether a request can register with either a web or OS provided Attribution Reporting API.
The EVENT.md explainer already adds an outgoing request header, Attribution-Reporting-Eligible, which specifies what type of registrations are possible for the response (event-source, trigger, navigation-source).
To simplify this, we could consider combining the two headers. Because both are already structured dictionary headers, it would simple to allow them to contain all of the boolean keys (event-source, trigger, navigation-source, os, web).