Report errors in HTTP fields for measureConversion

[martinthomson]

In looking at #328, I realized that if the browser receives a field that requests conversion measurement, it does not do anything if there is an error. Any rejection of the promise that conversion measurement returns is simply ignored.

This is probably a good case for using application/problem+json. Posting that to the report URL requires that the URL be functional, which in turn means that the RFC 9651 parsing can't be the source of the error, but we can reorder processing so that the URL is the first thing we recover.

The code would also need to be restructured a little to support error reporting, because that is currently only something that happens if the entire process succeeds.

[apasel422]

I'm supportive of error reporting here, but is the application/problem+json RFC actually meant for this use case? From a quick read, it seems more applicable to errors originating from REST API servers, rather than individual HTTP headers handled by the browser.

Maybe the Reporting API is more suitable for telling the server about errors resulting from the Measure-Conversion header, especially since, as you point out, we would need to extract the report URL from the header, but the header itself may be the source of the error?

That would also allow it to work naturally with Save-Impression, without having to add in some kind of error-report-url field there.