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
{{ message }}
Repository navigation
Could there be a way to collect Crash/Intervention reports without collecting Deprecation reports? #263
I ask because a proxy downstream of my site appears to be adding the Expect-CT header, which is causing my reporting server to be spammed with "Expect-CT is depreciated" depreciation reports. To stop the flood of reports, I have no choice but to stop collecting Depreciation, Intervention and Crash reports - when I only actually want to stop collecting Depreciation reports (or at least stop receiving that one report).
I can't contact the proxy (I don't even know for sure it exists or which of my clients might be using it), and I can't add a filter to the reporting server (it's a third-party service).
We should probably have a way to configure deprecation/intervention/crash reports independently of each other. I'm not sure where that configuration should go; maybe we should discuss in the WG.
Yes, I completely agree. It's also somewhat odd to me that you only receive deprecation, intervention etc. reports to the default reporting endpoint (or at least that was the case last time I checked).
That's still the case -- it made it really easy to configure, with the old Reporting header, but the downside is that you can't opt out of any of the three. There should be some way to configure these, and hopefully not requiring three additional headers.
I also add the following sample image. The volume received from type intervention is ~500% over the other ones, and, in our case, is useless:
I think that the network-error failure_fraction capability must be a requirement for all reporting types.
Taking the same syntax proposed in w3c/network-error-logging#133 could solve the problem inside the network-error body, but maybe it's easier to define a nel header to cover all the types. For example:
changed the title [-]Could there be a way to collect Crash/Intervention reports without collecting Depreciation reports?[/-][+]Could there be a way to collect Crash/Intervention reports without collecting Deprecation reports?[/+]on May 22, 2025
Activity
clelland commentedon May 8, 2023
We should probably have a way to configure deprecation/intervention/crash reports independently of each other. I'm not sure where that configuration should go; maybe we should discuss in the WG.
neilstuartcraig commentedon May 24, 2023
Yes, I completely agree. It's also somewhat odd to me that you only receive deprecation, intervention etc. reports to the
defaultreporting endpoint (or at least that was the case last time I checked).There's a similar proposal for NEL so perhaps the same syntax could be used in both for consistency.
clelland commentedon May 24, 2023
That's still the case -- it made it really easy to configure, with the old
Reportingheader, but the downside is that you can't opt out of any of the three. There should be some way to configure these, and hopefully not requiring three additional headers.aluhrs13 commentedon Jun 22, 2023
Could there be overlap between this and #45? Allowing sampling control per report type would probably handle both this issue and that one?
rfmoz commentedon Sep 25, 2023
I also add the following sample image. The volume received from type intervention is ~500% over the other ones, and, in our case, is useless:

I think that the network-error
failure_fractioncapability must be a requirement for all reporting types.Taking the same syntax proposed in w3c/network-error-logging#133 could solve the problem inside the network-error body, but maybe it's easier to define a nel header to cover all the types. For example:
[-]Could there be a way to collect Crash/Intervention reports without collecting Depreciation reports?[/-][+]Could there be a way to collect Crash/Intervention reports without collecting Deprecation reports?[/+]