CfC: server-sent-events

A couple of comments on the Server-Sent Events draft proposal:

Section 4:
When close() is called on the EventSource object, the initial connection may
not have been established yet, or a reconnection could be scheduled for some
arbitrary time in the future (not currently being attempted). Should the
line which reads

The close() method must close the connection, if any; must abort any
> reconnection attempt, if any; and must set the readyState attribute to
> CLOSED.


read, instead:
The close() method must close the connection, if any; must abort any
connection or reconnection attempt, if any; cancel any pending reconnection
attempts, if any; and must set the readyState attribute to CLOSED.

Section 5:

> Only if the user agent reestablishes the connection does the connection get
> opened anew!


The link in this sentence unhelpfully just points back to the same paragraph
that it appears in. Should this just be taken to mean that if the user agent
isn't in a state of "having to re-establish the connection", then it
shouldn't attempt to re-open the connection?

The way it is written, and emphasized, I read it several times, thinking it
was some kind of critical security measure, but after some thinking, it
seems just to be saying the same thing as the next paragraph: "Once the user
agent has failed the connection, it does not attempt to reconnect".

Section 7:

> When the user agent is required to dispatch the event, then the user agent
> must act as follows:


> 1. If the data buffer is an empty string, set the data buffer and the event
> name buffer to the empty string and abort these steps.


> 2. If the data buffer's last character is a U+000A LINE FEED (LF)
> character, then remove the last character from the data buffer.


> 3. Otherwise, create an event that uses the MessageEvent interface, with
> the event name message, which does not bubble, is not cancelable, and has no
> default action. The data attribute must be set to the value of the data
> buffer, the origin attribute must be set to the Unicode serialization of the
> origin of the event stream's URL, and the lastEventId attribute must be set
> to the last event ID string of the event source.


The word "Otherwise" does not belong at the beginning of point 3 (unless a
trailing LF aborts the message event). It may belong at the beginning of
point 2, but does not appear to be strictly required (as point 1 aborts).


Q: Last-Event-ID HTTP Header
What is the result of a proxy dropping the Last-Event-ID header? (I'm
assuming here that old or misconfigured caches may silently drop headers
which they do not recognize.)  It is only sent on a reconnection attempt, so
the client has likely seen some of the event stream. The server would see
this as a new connection, however. My reading of the proposal suggests that
the server could start the event stream from the beginning again, or that it
could start sending live events from the current time forward, possibly
missing any that occurred during the reconnection timeout, which might have
been sent had the header not been dropped.

There does not seem to be a requirement for the server to use an event ID on
the first message in the connection, and if it does not, then the client
would use its own lastEventId as the event ID for the first message or
messages in the stream (until the server uses an "id" field to
re-synchronize).

I would suggest that a server, if it uses IDs at all to identify events, be
encouraged to send an ID with at least the first message of any new
connection.


Q: Server-controlled termination of connection
Is there any method for the server to signal to the client that it has the
event stream has been permanently exhausted, and that it should close the
connection and not attempt to reconnect?

Short of an agreement by which an MessageEvent with a specific payload
informs the client that it should call close() on the EventSource object,
the only way I can see for the server to abort the connection is to forcibly
close the connection, and return an invalid Content-Type or HTTP status code
on a subsequent reconnection attempt. This would require the server to be
able to recognize the client, which may not be possible, or to realize that
the Last-Event-ID in the client request represents the end of the stream,
and force an error at that point.

It might be useful to have an message field name which indicates that the
server wishes to close the connection (or that it is about to close the
connection) and the no further events will be sent at that URI.


Q: Multiple EventSource objects to the same URI?
Can a user agent construct multiple EventSource objects referring to the
same URI? That appears to be the point (or at least part of it) of the note:

The definition of the fetching algorithm is such that if the browser is
> already fetching the resource identified by the given absolute URL, that
> connection can be reused, instead of a new connection being established. All
> messages received up to this point are dispatched immediately, in this case.


If that is the case, then it appears that they could all share the same
connection. If they do, then the the close() method needs to be redefined
such that either a close() call on one of the EventSources implicitly calls
it on the rest, or else the user agent needs to maintain a count of
EventSources currently using the connection, and the close() method should
just cancel reconnections, and set the readyState attribute, and only close
the connection when that count goes to zero.

-- 
Regards,
Ian Clelland
<clelland@gmail.com>