Initial detail of HTTP API #56
Conversation
api.bs
Outdated
| <a method for=PrivateAttribution>saveImpression()</a> API. | ||
|
|
||
| <pre class=example id=ex-save-impression-header> | ||
| Save-Impression: conversionSite=advertiser.example;histogramIndex=2;\ |
There was a problem hiding this comment.
Is it intentional that this is a single-key dictionary (conversionSite) with parameters for histogramIndex, filterData, and lifetimeDays?
Not suggesting it's wrong, but just making sure the intention wasn't for each of those last three to themselves be a top-level key, in which case the ; separator should be replaced with a space. Making them top-level keys is arguably more flexible, as they can themselves gain parameters over time, but it depends on what future changes, if any, we want this header to support. It's unclear to me if there's a benefit to making this a dictionary (rather than a single item) if there will only ever be one top-level key.
Related, would it make sense to allow multiple impressions to be registered in a single HTTP response? If so, maybe this should be a top-level list instead.
Finally, per https://httpwg.org/specs/rfc9651#rfc.section.3.2:
Member keys cannot contain uppercase characters.
So these might be more conventionally spelled like conversion-site. This also applies to parameters.
There was a problem hiding this comment.
Thanks @apasel422 for reviewing. I've tentatively changed it to commas (i.e. a top-level dictionary) so the definition is at least valid, but depending on the multiple impressions question and the necessary filterData expressiveness, we might want something else. I also added the multiple impressions question as a topic for the meeting.
There was a problem hiding this comment.
A top-level dictionary means that we will only permit a single impression to be saved. It is possible to add some structure to parameters like list=(this is a list of seven items) but the syntax is a bit unnatural, but it might be that those limitations will encourage good design... or at least creative design.
| Implementations parsing the header must accept any valid | ||
| [=structured header/item=] or [=structured header/inner list=]. | ||
| If the filter data is not understood, no impression is saved. |
There was a problem hiding this comment.
Are these sentences in conflict?
And what are the implications of the first sentence for how filter-data matching works?
There was a problem hiding this comment.
Yeah, it doesn't make a lot of sense as written. I was trying to allow for extensibility of the filter data in the future, but not saving an impression sounds a lot like rejecting the filter data.
No description provided.