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.

Hi Alessio, 

For the LF issue, I already sent PRs [1] [2] to fix in resteasy.  For SseEventSource.register(... Runnable onComplete) , I'll have a look this week.

[1]https://github.com/resteasy/Resteasy/pull/1277

[2]https://github.com/resteasy/Resteasy/pull/1276

Cheers,

Jim

On Tue, Sep 19, 2017 at 6:57 AM, Alessio Soldano <asoldano@redhat.com> wrote:

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?

Thanks

Alessio

On Mon, Sep 4, 2017 at 10:29 AM, Stephane Epardaud <stef@epardaud.fr> 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 another.

  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
resteasy-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/resteasy-dev