HTTP API for Measure Conversion #280

apasel422 · 2025-09-16T13:57:35Z

Fixes #31

Preview | Diff

martinthomson

This is the easy part. Getting the answer is the hard part.

api.bs

csharrison · 2025-10-14T23:22:54Z

Discussed in the Oct 14 call - let's wait to merge until we have support for sending the report.

apasel422 · 2025-10-15T12:24:53Z

Discussed in the Oct 14 call - let's wait to merge until we have support for sending the report.

I think we need to deal with #189 first.

api.bs

apasel422 · 2025-12-16T17:13:56Z

@martinthomson Please take another look.

impl/src/http.ts

api.bs

impl/src/http.ts

martinthomson · 2025-12-17T01:49:46Z

api.bs

+    ::  "`no-store`"
+    :   [=request/keepalive=]
+    ::  true
+1. [=Fetch=] |request|, optionally retrying in the event of an error.


Is the optional retry a feature of keepalive? If it isn't, should it be. It seems a bit wrong to include that capability here specifically, when the overall goal of keepalive is to make that sort of thing possible generically.

I don't believe automatic retry is inherent to keepalive, based on the MDN documentation. That said, I've been reading more about keepalive, and it's unclear to me if we want or need to use it here, and in general it opens a question about what entity is making the report-transmission request here.

I'd argue that the Attribution API's need to send reports is similar to https://w3c.github.io/reporting/, in that the report-creation step is asynchronous, and not necessarily done within the context of a page. We may want to take inspiration from https://w3c.github.io/reporting/#try-delivery, or at least get advice from someone else about this.

https://fetch.spec.whatwg.org/#fetch-elsewhere-request also implies something along those lines:

If your fetching is not directly web-exposed, e.g., it is sent in the background without relying on a current Window or Worker, leave request’s client as null and set the request’s origin, policy container, service-workers mode, and referrer to appropriate values instead, e.g., by copying them from the environment settings object ahead of time.

I added some inline issues to the spec to discuss this, but would appreciate your thoughts.

That text is about fetches that have no real connection to any active realm. That's not the case here as we always have a Window involved. (We're not presently talking about a Worker, though we could use the Worker's settings object if we wanted to.)

Reporting basically deliberately disassociates the report sending from where the reports are collected. I don't think that's the case here. We're only attaching the HTTP API to fetches that have direct effect on an active window, so we rely on having an active context.

api.bs

martinthomson · 2025-12-17T01:55:35Z

api.bs

+    ::  true
+1. [=Fetch=] |request|, optionally retrying in the event of an error.
+
+Issue: Should the request use a more specific content-type?


If we're doing DAP only for now, we could hard-code this. Or we could put the content type into the value we supply and interrogate that. We could add to AttributionConversionResult.

The caller of the API is at least theoretically aware of what protocol is being used, even if we support something other than DAP, as the caller chooses the aggregation service, so I'm somewhat reluctant to redundantly include it as part of the request body, which would mean defining some wrapper format around just the encrypted bytes of the report.

In other words, I think whatever we choose should just go in the Content-Type header. Does DAP have an existing media type? If not, we could consider registering one but go with application/octet-stream for now.

Yes, DAP has a media type, but from our perspective, we'd need to add that to AttributionConversionResult to get it through to this point (unless you wanted to play games with slots, I guess).

api.bs

Co-authored-by: Martin Thomson <[email protected]>

martinthomson

Hopefully, these responses help.

I'll not be around for a few weeks. I'm happy for you to merge on the basis of the suggestions I've made; though if you want to discuss more, you might either have to be patient or open issues to track those.

martinthomson · 2025-12-18T05:29:59Z

api.bs

+Issue: Should the request's [=request/service-workers mode=] be "`none`" instead
+of the default of "`all`"?


I would tentatively say no. Whatever keepalive does is fine here.

martinthomson · 2025-12-18T05:32:43Z

api.bs

+    ::  "`no-store`"
+    :   [=request/keepalive=]
+    ::  true
+1. [=Fetch=] |request|, optionally retrying in the event of an error.


That text is about fetches that have no real connection to any active realm. That's not the case here as we always have a Window involved. (We're not presently talking about a Worker, though we could use the Worker's settings object if we wanted to.)

Reporting basically deliberately disassociates the report sending from where the reports are collected. I don't think that's the case here. We're only attaching the HTTP API to fetches that have direct effect on an active window, so we rely on having an active context.

martinthomson · 2025-12-18T05:40:42Z

api.bs

+Issue: Should the request's [=request/service-workers mode=] be "`none`" instead
+of the default of "`all`"?
+
+Issue: Should the request's [=request/unsafe-request flag=] be set?


This is largely moot. We're using POST with something other than application/x-www-form-urlencoded, so we'll be doing a preflight for any report. We can't really avoid doing that, and nor should we try. Enterprises might not like us pushing these reports at random servers, even though the opportunity for attack seems very much remote (no site can really control the content of reports).

martinthomson · 2025-12-18T05:42:41Z

api.bs

+Issue: Should the request's [=request/referrer=] be "`no-referrer`" instead of
+the default of "`client"`?


For this, it might make sense to use |url|. Setting this to "client" will mean no referer header, which isn't quite right for this.

martinthomson · 2025-12-18T05:45:23Z

api.bs

+Issue: Should the request's [=request/destination=] be something other than the
+default of the empty string, e.g. "`report`" or even a new value?


Empty seems right. We'll be keeping good company. We could attempt to define a destination, but I believe that that is possible to do later, if we think that the destination might help us do something special, like have specific CSP rules. Right now, I think we're OK relying on permissions policy and the standard connect-src rules from CSP, but we might decide to add a CSP-level control in future for this.

martinthomson · 2025-12-18T05:45:38Z

api.bs

+Issue: Should the request's [=request/redirect mode=] be something other than the
+default of "`follow`"?


The default works fine.

martinthomson · 2025-12-18T05:45:50Z

api.bs

+Issue: Should the request use a `null` client instead, per
+<a href="https://fetch.spec.whatwg.org/#fetch-elsewhere-request">the `fetch`
+specification's guidance</a>?


I don't think that applies, see above.

martinthomson reviewed Sep 22, 2025

View reviewed changes

api.bs Outdated Show resolved Hide resolved

apasel422 force-pushed the conv-http branch from 41307b2 to c8a91ed Compare September 23, 2025 13:21

apasel422 force-pushed the conv-http branch 2 times, most recently from a2d8c3b to 2cb35d5 Compare November 19, 2025 15:43

apasel422 force-pushed the conv-http branch from b7e9cf9 to fc135ae Compare November 24, 2025 13:42

apasel422 marked this pull request as ready for review November 24, 2025 13:44

apasel422 requested review from csharrison and martinthomson November 24, 2025 13:44

apasel422 force-pushed the conv-http branch from fc135ae to 9db3686 Compare December 2, 2025 13:51

apasel422 mentioned this pull request Dec 2, 2025

Minor reorganization of HTTP-parsing spec/code #326

Merged

csharrison approved these changes Dec 2, 2025

View reviewed changes

api.bs Outdated Show resolved Hide resolved

csharrison mentioned this pull request Dec 2, 2025

Request with credentials included, but only if they are partitioned whatwg/fetch#1892

Open

apasel422 force-pushed the conv-http branch from 3135960 to 8e5202c Compare December 3, 2025 13:07

apasel422 mentioned this pull request Dec 3, 2025

Consider advertising implementation-defined parameters in JS and HTTP #328

Open

apasel422 force-pushed the conv-http branch 2 times, most recently from 091765c to 578defb Compare December 10, 2025 14:23

apasel422 added 2 commits December 15, 2025 08:13

Add Measure-Conversion HTTP header

b9ee48a

Implement Measure-Conversion parsing in simulator

0e78f32

apasel422 force-pushed the conv-http branch from 578defb to 0e78f32 Compare December 15, 2025 13:13

martinthomson reviewed Dec 17, 2025

View reviewed changes

apasel422 and others added 7 commits December 17, 2025 08:07

Update api.bs

1d4c8ae

Co-authored-by: Martin Thomson <[email protected]>

Update impl/src/http.ts

0823de4

Co-authored-by: Martin Thomson <[email protected]>

Update impl/src/http.ts

e53b0c4

Co-authored-by: Martin Thomson <[email protected]>

Update http.ts

e65eab7

Update http.ts

0a23274

Update api.bs

e08f8c9

Co-authored-by: Martin Thomson <[email protected]>

fix

50d1002

apasel422 added 4 commits December 17, 2025 08:22

omit credentials

91aefcd

Note ignored keys/params

1ed4802

todos

c22f1a2

Parsing helpers

b29fba5

apasel422 force-pushed the conv-http branch from c1a8ad2 to b29fba5 Compare December 17, 2025 15:03

apasel422 requested a review from csharrison December 17, 2025 15:05

martinthomson approved these changes Dec 18, 2025

View reviewed changes

		Issue: Should the request's [=request/service-workers mode=] be "`none`" instead
		of the default of "`all`"?

		Issue: Should the request's [=request/referrer=] be "`no-referrer`" instead of
		the default of "`client"`?

		Issue: Should the request's [=request/destination=] be something other than the
		default of the empty string, e.g. "`report`" or even a new value?

		Issue: Should the request's [=request/redirect mode=] be something other than the
		default of "`follow`"?

HTTP API for Measure Conversion #280

Are you sure you want to change the base?

HTTP API for Measure Conversion #280

Conversation

apasel422 commented Sep 16, 2025 • edited by pr-preview bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinthomson left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

csharrison commented Oct 14, 2025

Uh oh!

apasel422 commented Oct 15, 2025

Uh oh!

Uh oh!

apasel422 commented Dec 16, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

martinthomson left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

apasel422 commented Sep 16, 2025 •

edited by pr-preview bot

Loading