21:39
<zcorpan>
sideshowbarker: found another w3c HTML5 spec that's not redirecting https://www.w3.org/TR/2011/WD-html5-20110525/
22:22
<sideshowbarker>
zcorpan: pretty sure those versions with dated URLs are intentionally not redirected
22:23
<zcorpan>
sideshowbarker: oh, ok. Then at least I found and fixed links to such a dated URL
22:24
<sideshowbarker>
yeah I think in general if there are resources elsewhere which are referencing those dated URLs, the solution is to update the links
23:05
<karlcow>
foolip: https://bugs.chromium.org/p/chromium/issues/detail?id=1196138 we got another report for web-share self issue.
23:44
<sideshowbarker>

annevk: Does the answer at https://stackoverflow.com/questions/69673929/access-control-allow-origin-response-seems-to-be-getting-cached/69706903#69706903 sound correct?

Chrome will still use the cached header even if the origins differ and the Vary header is present and set to 'Origin' if the ETags still match.

To get past this either unset the ETag header or vary it based on request origin.

If so, is that non-conforming behavior? Or is it instead conforming per-spec? (per the HTTP spec requirements, I guess).

If it’s conforming, I wonder whether it’s something we should document in the Fetch spec (in the same note that currently covers using the Vary header).