[whatwg] Server-Sent Events parsing issue

Thanks Anne,

On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA
> <taka.atsushi at googlemail.com> wrote:
>>
>> It's a minor error in the spec in the Server-Sent Events spec.
>> http://dev.w3.org/html5/eventsource/#event-stream-interpretation
>>
>> When processing a line with only "data:", the data buffer will be the
>> empty string and the LF character added at the "process the field"
>> stage. When dispatching the event, the first step "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." does not apply here (since we
>> have the LF character, which will be removed in the step 2). So it
>> does fire a MessageEvent with an empty string as the data property.
>>
>> I think the steps 1 and 2 of the dispatching should be the other way
>> round.
>
> Why would we not want to dispatch an event where data is the empty string in
> this case? I do not think this is an error. (Although admittedly I once
> thought it was.)
>

Well, in that case the example should be re-written:

= http://dev.w3.org/html5/eventsource/#event-stream-interpretation

The following stream fires just one event:
data

data
data

data:

The first and last blocks do nothing, since they do not contain any
actual data (the data buffer remains at the empty string, and so
nothing gets dispatched). The middle block fires an event with the
data set to a single newline character.

= up to here

It's slightly out of topic, but what's the idea behind making a line
without a semicolon make the whole line the "field"? The 3 out of 4
possible "field" names, "event", "id" and "retry" make no sense
without the value. Also "data" line without any message seems useless
to me, and even if you do want it without a message "data:" does the
job.

A. TAKAYAMA

Received on Thursday, 14 October 2010 05:23:41 UTC