I also have fixes in my two current PRs for that, because I had to fix
this for my tests, but I can remove my own SSE LF fixes if you merge his
PRs first, since they should fix the same issues, no problem.
On 19/09/17 10:30, Jim Ma wrote:
For the LF issue, I already sent PRs   to fix in resteasy. For
SseEventSource.register(... Runnable onComplete) , I'll have a look
On Tue, Sep 19, 2017 at 6:57 AM, Alessio Soldano <asoldano(a)redhat.com
Hi Stephan, hi Jim
looks like you had some private discussion on the topics mentioned
here. Is anything sorted out or something still needs to be worked?
On Mon, Sep 4, 2017 at 10:29 AM, Stephane Epardaud
<stef(a)epardaud.fr <mailto:firstname.lastname@example.org>> wrote:
On 04/09/17 07:59, Jim Ma wrote:
> On 09/02/2017 12:04 AM, Stephane Epardaud wrote:
>> Sorta related: you add a newline at the end of the data read
>> via SSE in the client, but that's not correct: the NL should
>> only be added if you have more than one 'data' field after
> From https://html.spec.whatwg.org/#processField
;, the line feed
> is always added to data buffer. But now sse client missed
> this step the remove the last character from if it is a LF.
Yes, true. But the effect is the same in that users end up
with one LF too many ;)
>> And similarly, you should really do some escaping when
>> serialising SSE data, because \n and \r are special chars.
>> I'm pretty sure as it is, it's not valid SSE.
> Should we escape these character ? Or we need to write
> another data field when meet these chars ?
Well, this spec has no escaping, that I can find. But yes if
we do meet a LF (or any other allowed terminator, because I'm
not sure LF is the only one), we should start a new `data: `
line. This will at least deserialise properly on the other end.
resteasy-dev mailing list