Incomplete message parsing about eventsource HOT 8 CLOSED

Could it be that #108 (released in 1.0.6) introduced a regression?

Contributors: I think we need to add some fuzz testing.

from eventsource.

We're using 1.0.5 so that wouldn't have caused our problem.

from eventsource.

Could you try upgrading to 1.0.6?

from eventsource.

Upgrading to 1.0.6 has the same issue.

I can also see that a random message comes in before the properly formed one I am waiting for, and that is the exact character length of that characters missing. Could this be an issue with character chunking/content length?

69

id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":4

from eventsource.

This looks like chunked transfer encoding. We should have a look at handling this

from eventsource.

Actually, node automatically decodes chunked transfers, so this shouldn't be the case. Does this happen often enough that you could try replicating it in the browser with the native EventSource API?

Could you get hold of the response stream from something like curl?

from eventsource.

Closing this issue - I don't think it is being caused by EventSource.

Just found that we are seeing two octets for a message, I imagine one is the octet meant for the following message and causing the first to be cutoff:

69
69
id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":41}

id: 52
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":42}

This explains why we see:

69
id: 51
data: ProjectionChannel@OrderUpdated {"id":"55bf136a15e9415985aed687b5a13cdb","streamRevision":4

from eventsource.

We are thinking this might be a ServiceStack related bug, or some C# layer responsible for the chunked encoding.

from eventsource.