Add Last-Event-ID to CORS-safelisted request headers

[rexxars]

Since EventSource implementations in most environments already send this header without CORS preflight request, it makes sense to make it a safe-listed header.

See #568 for more background.

• At least two implementers are interested (and none opposed):
  • WebKit
  • Gecko
• Tests are written and can be reviewed and commented upon at:
  • Add Last-Event-ID to CORS-safelisted headers web-platform-tests/wpt#49257
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/401528898
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1952605
  • WebKit: https://bugs.webkit.org/show_bug.cgi?id=289396
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

@yoichio @KershawChang @youennf any final thoughts?

[annevk]

Please add your name to the Acknowledgments section! (Not required.)

[rexxars]

Please add your name to the Acknowledgments section! (Not required.)

Thanks! Done :)

[smaug----]

Gecko is interested, but how likely will this cause some webcompat issues?

Is #568 (comment) about the relevant change? Those numbers are going up, but still rather low.

Edit: looks like it was discussed here #568 (comment)

[rexxars]

From the WHATNOT meeting on 2024-12-05:

PA: haven't seen any comments from Chromium, assume Domenic is still looking. Let's wait for that and the response from the PR author on web compat.

👋 PR author here.

@yoichio commented on the related issue with this link which contains some statistics on this. It seems to me like these numbers are still very low, but I am also not a browser developer/maintainer, so I don't know what is generally considered low numbers on these sort of topics.

I'm interesting in moving this forward - it seems to have interest from Gecko and WebKit, and I have not heard any opposition yet. Should this be raised again in an upcoming WHATNOT meeting, or is there something I can do on my side to move this along?

[annevk]

Implementation bugs still have to be filed. That would help a bit. I'l flag it for the next meeting as well to check there's no opposition. (If you're up for it implementing it in a browser can also do wonders.)

[rexxars]

I've filed implementation bugs, as well as pull/change requests with Chromium, Gecko and WebKit.

Happy to also open an MDN issue/pull request, but assume this should first be accepted into the spec?

[annevk]

@rexxars you can file an MDN issue now. In principle this is ready to land in the specification, but I'm a little worried that the browser patches don't seem to account for EventSource also having to go through this code path. We don't just want to safelist this header. We also want to make sure the existing use of this header abides by the safelist rules.

cc @ricea

[rexxars]

In principle this is ready to land in the specification, but I'm a little worried that the browser patches don't seem to account for EventSource also having to go through this code path. We don't just want to safelist this header. We also want to make sure the existing use of this header abides by the safelist rules.

I realized this myself after your feedback on the WebKit change, thank you for that. I will go through each of the patches and ensure that they test both safe and non-safe last-event-id values for both fetch, XMLHttpRequest and EventSource - and ensure that the new WPT tests fail before the change and pass after the change. Will revisit once I've done that.

[rexxars]

One thing I realized while implementing this in browsers;

The EventSource spec says to set Cache-Control to no-cache. Since this is not a safelisted CORS header and you change the preflight policy to "consider", it leads to browsers performing a preflight request with access-control-request-headers: cache-control. If they later get an unsafe last-event-id, another preflight is done, this time with access-control-request-headers: cache-control, last-event-id. This is probably not what we want - we should treat cache-control (from EventSource) as "safe".

In the Gecko codebase this was fairly easy to implement since you manually have to tell it which headers to consider. In WebKit and Chromium however, you only set the preflight policy to consider and the network layer takes care of the rest. This is tidier from a code perspective, but makes this change harder. I am not quite sure how to best go about making this change - maybe there needs to be a way to set headers that are "safe", CORS-wise, on a request? 🤔

[annevk]

Oh that does make this harder. Hmm. What Gecko does is a hack that I wish were not possible as it could allow for all kinds of shenanigans we don't really want to allow.

We'd either have to set the Cache-Control header at a later stage (though that would likely impact service workers as well) or specifically safelist that header name and value combination as well.

@ricea @smaug---- thoughts?