W3C home > Mailing lists > Public > public-html@w3.org > October 2007

Detailed review of 6.2. Server-sent DOM events

From: Mihai Sucan <mihai.sucan@gmail.com>
Date: Wed, 10 Oct 2007 21:59:59 +0300
To: public-html <public-html@w3.org>
Message-ID: <op.tzzwd9ndmcpsjgr0b0dp@athlon>


I have reviewed the section 6.2. "Server-sent DOM events" [1] from the  
HTML 5 specification. Here are my comments.

1. Regarding section 6.2.2. "Connecting to an event stream" [2] it's  
defined that:

"If such a resource completes loading (i.e. the entire HTTP response body  
is received or the connection itself closes), the user agent should  
request the event source resource again after a delay of approximately  
five seconds."

The event source resource polling interval cannot be defined by Web  
authors. Shouldn't this be configurable somehow? The 5 seconds delays  
seems completely arbitrary.

After I wrote the above, I looked into the source code of the spec  
section. It seems Lachlan Hunt also suggested this. Why keep this feature  
only for the next version?

It seemed as an obvious feature while reading the spec.

2. In section 6.2.4. "Interpreting an event stream" [3], there's a typo in  
the definition of the Class field, first phrase:

"This field gives *is* the interface used for the event, for instance  
Event, UIEvent, MutationEvent, KeyboardEvent, etc. "

Correction: remove "is".

3. Why does the specification define "comments" in the stream?

Given it does, why must the UA fire the message event when a comment is  
sent? There's no use to do so, other than having an event listner which  
could figure out "hey, something is coming from the server, maybe they are  

4. The specification does not make any statements about the security  
implications of SSE.

There are possibilities to flood the UA with events. There's also the  
possibility to exploit security holes, or simply to crash the UA when  
sending specific binary data as application/x-dom-event-stream. The  
connection should be closed/forcefully terminated, in some cases.

Regarding security, I would suggest to restrict the allowed chars in field  
names to a-z, A-Z, 0-9, _ and -. This would allow the implementation to  
terminate parsing the entire line earlier in cases when garbage data is  
sent. If that's too limited, allow only certain Unicode blocks (maybe from  
0000 to 024F ?). [4]

For now, the spec requires UAs to support the usage of binary-named fields  
and values, which is rather overkill, I'd say.

I haven't tested yet, but I'm quite sure existing implementations (such as  
Opera) do not allow *any* field name, which would be valid within the  
current spec rules.

That's about all, for now.

[4] http://www.unicode.org/Public/UNIDATA/Blocks.txt

Mihai Sucan
Received on Wednesday, 10 October 2007 19:00:28 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:27 UTC