[whatwg] Server-Sent Events parsing issue

[ATSUSHI TAKAYAMA]

On Thu, Nov 25, 2010 at 11:55 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA
> <taka.atsushi at googlemail.com> wrote:
>>
>> 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.
>
> Maybe you are right and the specification is wrong (and the example is
> correct).
>
> http://tc.labs.opera.com/apis/EventSource/format-field-data.htm (this is
> written against the example; passes in Opera, fails in WebKit)
>
> I don't really mind which way we go here I think.
>
>
>> = 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.
>
> Maybe this should be tightened up indeed. I can update the test suite either
> way.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

I would say the simpler the rule is, the better.
So a line without colon should be ignored.
Also for the example in the spec;
-a single "data:" line followed by an empty line should fire a message
event with an empty string data, and
-two "data:" lines followed by an empty line should fire a message
event with an LF as data
(push every line followed by an LF, then remove the last LF and fire it)

A TAKAYAMA