289396 2025-03-07 21:47:20 -0800 CORS: Safelist Last-Event-ID 2025-03-14 22:48:14 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build All All NEW InRadar P2 Normal --- 1 espen webkit-unassigned annevk ap webkit-bug-importer oldest_to_newest 2101599 0 espen 2025-03-07 21:47:20 -0800 Filing an implementation bug for https://github.com/whatwg/fetch/pull/1788 - see issue for proposal and discussion to change the specification. When using `XMLHttpRequest` or `fetch`, sending a cross-origin request with a (safe) `Last-Event-ID` request header triggers a CORS preflight request with an `access-control-request-headers: last-event-id` header. However, when using the EventSource API, the same request does not. Thus, it makes sense to safelist the `last-event-id` header, as long as it has less than 128 characters and does not include any CORS-unsafe request header bytes. This enables users to build custom EventSource-compatible polyfills, without requiring the server to implement CORS for something that can already be bypassed by using EventSource. 2101794 1 ap 2025-03-09 18:15:47 -0700 Could you please clarify what makes EventSource-compatible polyfills necessary? 2101824 2 espen 2025-03-09 22:02:16 -0700 (In reply to Alexey Proskuryakov from comment #1) > Could you please clarify what makes EventSource-compatible polyfills > necessary? Just to be clear; polyfills is just one aspect of this - https://github.com/whatwg/fetch/issues/568 outlines why safelisting this header makes sense, as you can theoretically bypass this already with a cooperating server. As for the polyfill question, there are a ton of reasons why you'd want to provide a better API - the EventSource API leaves a lot to be desired: - Being able to subscribe to any event sent from the server (EventSource requires you to explicit list named events you want to subscribe to) - Being able to differentiate between connection errors and events named 'error' - Configurable reconnection policies - Better error handling (EventSource gives you little to no information whatsoever - not even status code) - Being able to set an initial Last-Event-ID - Including additional headers with the request (authorization is a common one) There are already polyfills out there that does a lot of this, but it's a shame that for the standard case of reconnecting after a disconnect, you need the server to be "compatible" with the polyfill by responding to a preflight request and allowing `last-event-id`, when that is not needed if using the `EventSource` API. As mentioned previously, this is sort of false security anyway, since you can use a cooperating server to redirect you and include a `last-event-id` without requiring a preflight request. 2101831 3 espen 2025-03-09 22:26:58 -0700 Pull request: https://github.com/WebKit/WebKit/pull/42180 2103502 4 webkit-bug-importer 2025-03-14 22:48:14 -0700 <rdar://problem/147104095>