Bug 289396 – CORS: Safelist Last-Event-ID

• Component: WebCore Misc.
• Status: NEW

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.

[Alexey Proskuryakov]

Could you please clarify what makes EventSource-compatible polyfills necessary?

(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.

Pull request: https://github.com/WebKit/WebKit/pull/42180

[Radar WebKit Bug Importer]

<rdar://problem/147104095>