Add iframe support for adAuctionHeaders to spec. #918
Conversation
This support is provided by a new adAuctionHeaders attribute on the iframe element that will have the same functional behavior as the adAuctionHeaders fetch flag, in that it will trigger the user agent to send the Sec-Ad-Auction-Fetch request header, and to remove `Ad-Auction-Signals` and `Ad-Auction-Additional-Bid` response headers, providing their values to the Protected Audience auction.
This support is provided by a new `adAuctionHeaders` attribute on the iframe element that will have the same functional behavior as the `adAuctionHeaders` fetch flag, in that it will trigger the user agent to send the `Sec-Ad-Auction-Fetch` request header, and to remove `Ad-Auction-Signals` and `Ad-Auction-Additional-Bid` response headers, providing their values to the Protected Audience auction. This is a continuation of WICG#883, which needed to be closed due to an merge conflict on rebase.
|
Thanks for the helpful feedback, Caleb! |
spec.bs
Outdated
| request with the <{iframe/adAuctionHeaders}> <a spec=html>content attribute</a> set to `true`. | ||
| In this case, the JavaScript code is retrieved as part of the iframe navigation response, | ||
| at which point the JavaScript code makes the call to {{Navigator/runAdAuction()}}, | ||
| and |config|["{{AuctionAdConfig/directFromSellerSignalsHeaderAdSlot}}"] can be immediately resolved. |
There was a problem hiding this comment.
If this is pretty much all a duplicate note, then I think I might just point to the one above manually, instead of copy it all. Not a big deal, up to you, but it'd be easier to maintain that way.
There was a problem hiding this comment.
I tried that initially, but ended up deciding it was clearer to keep them separate. They're close to the same, but with a few salient differences, most notably the name of the config field, and the more subtle difference that config["directFromSellerSignalsHeaderAdSlot"] can be can be specified directly without a Promise, whereas config["additionalBids"] cannot, and so needs to be a Promise that's immediately resolved. Especially if there's later divergence, I suspect it's easier to start these out as separate. Thanks.
Changing the adauctionheaders content attribute to be all-lowercase, adjusting the language intended to describe the response returned from the fetch call, and using the dfn autolink for `reflects`.
|
Thanks for the thorough review, Dom! |
The section for `Sec-Ad-Auction-Fetch` currently says that the `Ad-Auction-Signals` response header will be removed from the response and will instead only be used in Protected Audiences auctions. This change adds `Ad-Auction-Additional-Bid`, which is treated the same way.
| <div algorithm="iframe navigation patch"> | ||
| The following step will be added to the | ||
| <a spec="html">create navigation params by fetching</a> steps | ||
| after step "Let |request| be a new [=Request/request=], with ...": |
There was a problem hiding this comment.
This doesn't really matter much since I'm commenting on the monkey patch, but can [=Request/request=] be [=request=], or <a for=/>request</a>?
There was a problem hiding this comment.
It seems to point to something different: https://fetch.spec.whatwg.org/#concept-request-request (for [=Request/request=]) vs https://fetch.spec.whatwg.org/#concept-request (for [=request=]), so have to leave this as is. Thanks!
There was a problem hiding this comment.
Well we want to point to https://fetch.spec.whatwg.org/#concept-request, not https://fetch.spec.whatwg.org/#concept-request-request, so I think we should probably change this in a small follow-up PR.
There was a problem hiding this comment.
Ah, sorry, I got confused as to which line in the referenced spec we were matching. I had convinced myself that we were referencing step 28 of the Request constructor in the Fetch Standard ("Set this’s request to request."), which points to #concept-request-request, instead of the line we're actually referencing - step 3 of the "create navigation params by fetching" in the HTML standard ("Let request be a new request..."
I'll send a follow-up PR to fix this. I based this part on the equivalent section in the Topics API draft spec. I'll follow up with them to recommend that change there as well.
Thanks!
There was a problem hiding this comment.
Created #964. Thanks again!
SHA: d512d45 Reason: push, by JensenPaul Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This is a follow-up to WICG#918.
This support is provided by a new adAuctionHeaders attribute on the
iframe element that will have the same functional behavior as the
adAuctionHeaders fetch flag, in that it will trigger the user agent to
send the Sec-Ad-Auction-Fetch request header, and to remove
Ad-Auction-Signals and Ad-Auction-Additional-Bid response headers,
providing their values to the Protected Audience auction.
This is a continuation of #883,
which needed to be closed due to an merge conflict on rebase.
Preview | Diff