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.
[
Cheers,
Jim
On Tue, Sep 19, 2017 at 6:57 AM, Alessio Soldano <asoldano(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/resteasy-dev
>
>