Re: [whatwg] Server-Sent Events parsing issue
On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA taka.atsu...@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/
Re: [whatwg] Server-Sent Events parsing issue
On Thu, Nov 25, 2010 at 11:55 AM, Anne van Kesteren ann...@opera.com wrote: On Thu, 14 Oct 2010 14:23:41 +0200, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA taka.atsu...@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
Re: [whatwg] Server-Sent Events parsing issue
On Thu, 25 Nov 2010 18:21:35 +0100, ATSUSHI TAKAYAMA taka.atsu...@googlemail.com wrote: 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) That works for me. Hixie? People from WebKit? -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Server-Sent Events parsing issue
Thanks Anne, On Wed, Oct 13, 2010 at 10:00 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA taka.atsu...@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
Re: [whatwg] Server-Sent Events parsing issue
On Tue, 12 Oct 2010 06:41:59 +0200, ATSUSHI TAKAYAMA taka.atsu...@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.) -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Server-Sent Events parsing issue
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. A. TAKAYAMA
