Finish a todo of setting browserSignal's data-version field.

[qingxinwu]

Also provides "list" as a parameter to get structured head list as it
needs.

Also changed header's "true" to "?1" since the latter is the correct
true value for headers.

---

Preview | Diff

[qingxinwu]

@miketaylr Mind taking a look at the small change? Thanks.

[miketaylr]

lgtm

[dmdabbs]

    1. Set |dataVersion| to the result of [=header list/getting a structured field value=]
      given [:Data-Version:] and "`item`" from |headers|.
    1. If |dataVersion| is not null:
      1. If |dataVersion| is not an integer, or is less than 0 or more than 4294967295, set
        |signals| to failure and return.
      1. TODO: Check whether version is consistent for all keys requested by this interest group.

Was the data version at one time (or will be) an attribute within the response? Now it is a header value, so in what case might it differ across keys? Is there a possibility an IG's keys could be split across different signalsURL fetches?

BTW,

<dfn>fetch trusted signals</dfn>

is referenced elsewhere as [=fetching trusted signals=].

[qingxinwu]

Good question. Sent a PR to remove the TODO.
It was there because the explainer (browserSignals part) mentioned this. The explainer mentioned that just as an open option for a possible optimization of using multiple fetches for a generateBid's trustedBiddingSignals, but it's not what's implemented, and there's no plan of implementing it. So in the spec, going to remove the reference to that.

About [=fetching trusted signals=], it's a feature of bikeshed. "Bikeshed can automatically handle a wide range of English conjugations and pluralizations"

[dmdabbs]

About [=fetching trusted signals=], it's a feature of bikeshed. "Bikeshed can automatically handle a wide range of English conjugations and pluralizations"

谢谢 and 🤯