Rename response headers to match implementation.

[qingxinwu]

Rename response headers in both explainer and spec to use new headers in implementation. The request headers of "X-..." has been renamed (although the old headers are still supported to be backward compatible). See the bug that tracks the work.

• X-Allow-FLEDGE -> Ad-Auction-Allowed
• X-FLEDGE-Auction-Only -> Ad-Auction-Only

Not renaming X-fledge-bidding-signals-format-version since this header is going away soon.

---

Preview | Diff

[qingxinwu]

@JensenPaul Mind reviewing since the change? I can ask Caleb to review it instead if you'd like to.

[qingxinwu]

@domfarolino mind taking a look at the small change to the spec in this PR? Thanks!

[MattMenke2]

I'd rather we not rename X-fledge-bidding-signals-format-version. The goal is to remove it, and we're only seeing like 1% of requests using version 1.

[qingxinwu]

I'd rather we not rename X-fledge-bidding-signals-format-version. The goal is to remove it, and we're only seeing like 1% of requests using version 1.

Done.

[domfarolino]

Rename request headers to match implementation in both explainer and spec.

Do you mean "implementation and both explainer and spec"? If we were just renaming these to match the implementation, I'd expect renaming X-fledge-bidding-signals-format-version to be uncontroversial, but #772 (comment) says otherwise. So are we renaming these to match what the implementation already supports on stable, or are we skipping ahead past the implementation a lot? Or just a little?

[MattMenke2]

Rename request headers to match implementation in both explainer and spec.

Do you mean "implementation and both explainer and spec"? If we were just renaming these to match the implementation, I'd expect renaming X-fledge-bidding-signals-format-version to be uncontroversial, but #772 (comment) says otherwise. So are we renaming these to match what the implementation already supports on stable, or are we skipping ahead past the implementation a lot? Or just a little?

I don't think we want to ask people to update their code for something we hope to remove in maybe a month or two - we're only seeing this in 0.5% of requests, down from 1.5% a month ago, and print out a devtools warning on the old version. The new version allows new keys to be added to the top-level dictionary if we need new types of data, so hopefully it's not something we'll need in the future - if we need new versions, we could even just include them in the JSON response body, something we couldn't do before, since every key had a meaning.

I think we actually do support all the new headers, I just think in this case, we should not be advertising it, or have made the change in the first place. I wasn't a party to the code change here (was out on medical leave at the time), or I would have pushed back on it.

[qingxinwu]

Rename request headers to match implementation in both explainer and spec.

Do you mean "implementation and both explainer and spec"? If we were just renaming these to match the implementation, I'd expect renaming X-fledge-bidding-signals-format-version to be uncontroversial, but #772 (comment) says otherwise. So are we renaming these to match what the implementation already supports on stable, or are we skipping ahead past the implementation a lot? Or just a little?

I don't think we want to ask people to update their code for something we hope to remove in maybe a month or two - we're only seeing this in 0.5% of requests, down from 1.5% a month ago, and print out a devtools warning on the old version. The new version allows new keys to be added to the top-level dictionary if we need new types of data, so hopefully it's not something we'll need in the future - if we need new versions, we could even just include them in the JSON response body, something we couldn't do before, since every key had a meaning.

I think we actually do support all the new headers, I just think in this case, we should not be advertising it, or have made the change in the first place. I wasn't a party to the code change here (was out on medical leave at the time), or I would have pushed back on it.

Yes, for all the headers here, our implemention now supports both the new and old headers (to be backward compatible). We expect people to switch to new headers, and stop supporting old headers when no longer needed.
For the format version header, I agree with Matt that we don't advertise the new header (and better not have renamed it in the implementation), since we expect to remove the header soon and better let people continue using the old header.

[domfarolino]

Yes, for all the headers here, our implemention now supports both the new and old headers (to be backward compatible). We expect people to switch to new headers, and stop supporting old headers when no longer needed.

But will even the new headers be removed in a month or two, as Matt suggests? Or are they here to say?

[qingxinwu]

Yes, for all the headers here, our implemention now supports both the new and old headers (to be backward compatible). We expect people to switch to new headers, and stop supporting old headers when no longer needed.

But will even the new headers be removed in a month or two, as Matt suggests? Or are they here to say?

For the format version one, yes, the new header will be removed as well when the old one is removed.

[domfarolino]

Ah OK, and the other ones will continue to exist forever?

[MattMenke2]

No plans to remove any of the others, but the heat death of the universe is a pretty long ways off, so reluctant to commit to something on that timeframe.