Server-Sent Events feedback

On Fri, 15 Apr 2011, Ian Clelland wrote:
>
> 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).

Fixed.


> > 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?

Yeah. I've removed the sentence, it doesn't actually add anything.


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

Indeed. I added both sentences back in 2009 because there were some 
difficulties getting the point across with some early implementations, but 
just the second sentence is probably enough. :-)


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

Oops. Fixed. It was there because there used to be a step between 2 and 3 
that aborted, but that step is commented out at the moment.


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

Is that a safe assumption?


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

Yeah. Depends on the server.


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

It depends on how the script is written.


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

I'd rather not add such a warning unless we know it's a real problem.


> 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?

Sure, just send an event that the script understands means "close me".


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

Seems easier to just have the script close the stream.


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

Why isn't this something the script can do?


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

I've fixed this.


On Thu, 28 Apr 2011, Brett Zamir wrote:
>
> While I can understand that Server-Sent Events may be intending to start 
> off simple, I wonder whether there is some reason a formal mechanism was 
> not adopted to at least allow the specification of event types. I think 
> such a convention would have a number of important benefits.

What do you mean by "event type"?


> 1) The EventSource object could be optionally supplied with a particular 
> query string parameter (e.g., sse-type= or sse-types=) (if not also as a 
> key-value object second argument). If no other types were added, the 
> data stream itself would not need to encode type, although a type 
> property could still be set on the event object (see below). This would 
> allow a common convention, regularizing client-side and server-side 
> library creation, and in the case where only a single type were 
> specified, avoids the need for extra data to be added to the stream to 
> indicate type.

This can be done today, there's no need for the spec to change to allow 
authors to do this.


> 2) For cases where the application did wish to share a connection for 
> different types, an analogue to addEventListener could make it possible 
> for the client to notify the server to add more types to the stream 
> while reusing the same connection (though this would require some 
> additional mechanism, such as a different REST parameter like 
> "add-sse-type=" if not adding to a two-way stream). A type property 
> could then be made available on the response event object to allow the 
> user to be able to conveniently filter the types depending on the 
> response and the state of the client application, without the need for 
> hackish and non-uniform parsing of response data.

I don't follow what you mean here, possibly because I don't understand 
what you mean by "type".


> 3) Custom event types should be indicated by some unique mechanism 
> (e.g., requiring unrecognized types to be preceded by "x-") so that if 
> the specification were to be expanded upon in the future to support 
> official protocols, they could do so without impacting existing code. 
> However, when no type is supplied, this could also be assumed to be a 
> custom event, but without any "namespace". This would allow the 
> specification to be backwards-compatible.

Not sure what this means.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 17 June 2011 01:17:14 UTC