When to "fail the connection" of an EventSource?

[gterzian]

Question/possible bug:

The processing model of an EventSource mentions the following: "Any other HTTP response code not listed here, as well as the cancelation of the fetch algorithm by the user agent (e.g. in response to window.stop() or the user canceling the network connection manually) must cause the user agent to fail the connection."(emphasis mine)

The reference to window.stop() takes us to aborting a document load, which mentions in Step 2 "Cancel any instances of the fetch algorithm in the context of document", and also to "discard any tasks queued for them".

So the way I read it, when the fetch associated with an EventSource is cancelled, per the 'processing model' we should then move on to fail the connection, which means queuing a task, presumably on the networking task source, to do so.

So let's assume the following processing model:

1. We start a fetch for an EventSource in a document.
2. window.close() is called on that document's window.
3. We cancel all fetches for that document, in this case the one started at 1.
4. As part of cancelling the EventSource fetch, we 'fail the connection', meaning we queue a task to do that. Presumably this would be done on the networking task source.
5. We should then "discard any tasks queued for them(the canceled fetches)".

Does 5 not imply also cancelling the 'fail the connection' task?

Potential solutions I can think of:

1. In the context of the user agent canceling the fetch, "failing the connection" immediately, not via a task. This would mean firing the 'error' event on EventSource as part of the cancellation.
2. Removing the "as well as the cancelation of the fetch algorithm by the user agent" part of the processing model, so that there is no ambiguity and we basically decide that the connection will not be 'failed' in that case. This would bring 'cancelling the fetch by the user agent' in line with the close method, which doesn't seem to reference 'failing the connection' either. Neither does forcibly closing the EventSource as part of document unloading(which is arguably pretty close to 'cancelling the fetch by the user agent').

For clarity, the only difference between 'failing the connection' or not, as part of (forcibly)closing an EventSource, is whether an 'error' event will be fired.

What do you think?

[gterzian]

Allright, just reading in the spec that all tasks for the EventSource should be queued to the remote event taks source. In Servo, we seem to use the networking task source, so in fact the solution to my problem would be to:

1. Use the remote event taks source
2. When aborting a document, only tasks queued on the 'networking task source' will be discarded.
3. Result: one could indeed 'fail the connection' via a task, queued on the 'remote event task source', and it will not be discarded as part of document aborting...

If this logic is correct, this issue can be closed...

[domenic]

Yeah, your logic looks correct. Sorry about the implicit-ness of the task sources; we do that in a few places in the spec, and it's not great. But I agree with your conclusion.

[gterzian]

Ok, thanks for having looked into it!