should Cache API Vary matching use combined header values?

[wanderview]

At some point the fetch spec was changed such that Headers.get() now returns combined values. The SW spec was using Headers.get() for Vary header matching previously and I don't think it was updated to account for this change.

What is the intention here? Should Cache API vary matching be performed on combined values (new fetch get()) or first header value (old fetch get())?

@jakearchibald @annevk @inexorabletash

[annevk]

Wait, why did Cache API use headers.get()? Did it actually use the JavaScript call? That seems almost certainly broken. And even if not, not considering all headers seems to break with HTTP, no?

[wanderview]

If http cache considers all headers, then I think the spec is mostly correct now.

In regards to calling webidl calls, it seems fetch spec does not expose algorithms that can be used instead?

[annevk]

I'd expect the Cache API to just operate on the data structure directly, as it does earlier on Query Cache as well, e.g., "If cachedResponse’s response’s header list contains no header named Vary".

[annevk]

We can certainly add algorithms if Cache API needs particular abstractions that are likely reused elsewhere though.

[annevk]

I think this can be closed with the remaining issue dealt with in #1609. @wanderview what do you think?

[wanderview]

SGTM.