Expand HTTP No-Vary-Search header data

[tunetheweb]

Summary

Expand No-Vary-Search data, splitting out prefetch and prerender to separate keys and also add HTTP Cache support

Test results and supporting details

For HTTP Cache:

1. Visit: https://www.tunetheweb.com/ using Chrome 127 or above
2. Open DevTools
3. Make sure "Disable cache" is unticked
4. Add random ULR params (e.g. https://www.tunetheweb.com/?test=1234)
5. Note the resource is served from the Disk cache

https://chromestatus.com/feature/5808599110254592

Related issues

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[tunetheweb]

Pinging @Elchi3 and @caugner who's reviewed my previous PRs. Can one of you (or someone else) review this?

Apologies if it's already on your TODO list — just making sure it didn't fall through the EOY cracks.

[caugner]

Were HTTP cache and the speculation rules features added later to the spec? If not, I think it would make more sense to keep a partial implementation entry for versions that don't support the full spec, with one note per unsupported feature:

Suggested change

	"chrome": {
	"version_added": "121"
	},
	"chrome": [
	{
	"version_added": "141"
	},
	{
	"version_added": "121",
	"version_removed": "141",
	"partial_implementation": true,
	"notes": [
	"Before Chrome 127, speculation rules are only supported for navigational prefetch, not prerender.",
	"Before Chrome 141, HTTP cache is not supported."
	]
	}
	],

[tunetheweb]

So there's an interesting history with this, which makes it kind of complicated...

It was originally designed and implemented for Speculation Rules. And was part of the Speculation Rules spec.

Then it was generalised for use for any cache and moved to an IETF standard proposal (https://datatracker.ietf.org/doc/draft-ietf-httpbis-no-vary-search/) with Speculation Rules spec updated to refer to this (as it has some nuances on top).

Saying that, I think the HTTP Cache is an important use case (hence why I'm trying to document this!). So I'm OK saying this is partially supported before then. Though isn't that a little repetitive of the individual keys below?

[caugner]

Apologies for not being clearer and more consistent earlier. Unfortunately, we now have duplicated data between notes in the parent feature and the subfeatures.

Could we consider HTTP cache the primary part of the implementation (and remove the "http_cache" subfeature):

{
  "version_added": "141"
},
{
  "version_added": "121",
  "version_removed": "141",
  "partial_implementation": true,
  "notes": "Does not use responses from HTTP cache."
}

As for the speculation rules subfeatures, could we combine those into a single speculation_rules subfeature?

{
  "version_added": "127"
},
{
  "version_added": "121",
  "version_removed": "127",
  "partial_implementation": true,
  "notes": "Only uses responses from navigational prefetch catch, not from prerender cache."
}

Overall, we're trying to avoid unnecessary subfeatures.

PS: In doubt, it would be valuable to get another opinion from @ddbeck.

[tunetheweb]

This is exactly what I struggled with :-)

Could we consider HTTP cache the primary part of the implementation (and remove the "http_cache" subfeature).

Given that came later that's not possible. As the primary version can't be later than a sub-feature. That's why I went with just the earliest support for primary, without any note, and then the three sub-features (even though one of them had the same initial version as the overall feature).

As for the speculation rules subfeatures, could we combine those into a single speculation_rules subfeature?

We could, but 1) they were supported in different versions so requires a partial implementation so questionable if that's better. More importantly though is 2) it's looking increasingly like other browsers will implement prefetch first (Safari already has an implementation behind a flag, but without No-Vary-Search support at present). And Firefox is experimenting with prefetch speculation rules. So we'd likely want to split these out anyway.

Overall, we're trying to avoid unnecessary subfeatures.

Totally understand, but I honestly think 3 sub-features, and an overall feature (without the note we added in this review), is needed and also is the clearest way of displaying this.

But happy to hear your or @ddbeck 's thoughts.

[caugner]

Totally understand, but I honestly think 3 sub-features, and an overall feature (without the note we added in this review), is needed and also is the clearest way of displaying this.

Alright, you have convinced me! 🙂