Strictly define how JSONs are separated in GRPC gateway

[socketpair]

I use GRPC gateway to access etcd watching functionality. Namely, https://github.com/etcd-io/etcd/blob/master/Documentation/dev-guide/api_grpc_gateway.md#watch-keys .

But I don't have any specifications on how should I separate JSONs in the response stream since it is not documented anywhere.

Basically I have 3 ways:

1. HTTP chunk = message
   This fails at least in Fedora 31 on high load because sometimes bare newline \n appears as a separate chunk. In order to fix you probably should first concatenate JSON with \n before calling to Write(). Also, intermediate proxies may re-chunk stream.

2. Messages are separated using strictly one newline.
   It is not documented as well, and comment in GRPC gateway states that newline is added just to simplify debugging. Somewhere in the net, I found that other software uses a double newline for that purpose (allow to divide messages containing formatted JSON). Currently, I choose this way.

3. Use JSON finite state machine to detect end of a message.
   This way will work in any case, but technically this requires additional libraries for the majority of programming languages.

So, Please strictly document exact behavior (protocol) which should be considered for implementing JSON stream parser.

Original issue:
grpc-ecosystem/grpc-gateway#1086

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[socketpair]

Hay! It's still actual

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

BUMP. Still actual.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

It is still actual!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

No, it's not stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

No, it's not stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

It's actual

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

Still actual

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

Still

[nic-6443]

We encountered the same problem, as there is no clear way to split messages, resulting in the client not being able to handle receiving partial messages or multiple messages in one HTTP chunk when ETCD is proxied by an HTTP server like nginx.

[nic-6443]

Special attention needs to be paid to ETCD v3.3.0, because of a bug in grpc-gateway v1.3.0(ETCD v3.3.0 depended on), the way of using newlines as separators will fail.
See:

• Backwards incompatible change to chunked encoding grpc-ecosystem/grpc-gateway#495
• Streaming forward handler fix chunk encoding grpc-ecosystem/grpc-gateway#479

[socketpair]

Happily I switched to websocket transport.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

Still actual.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

Bump

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.

[socketpair]

.