While this seems good to have a more efficient transport, I can't make sense of this
> Since the subsequent IETF drafts 30 and 31 do not have compatibility-breaking changes, we currently are not planning to change the over-the-wire identifier.
Are there slow-moving internal software at Google that relies on this nonce? This looks like the kind of thing that some clients will tend to rely on (for a reason yet unknown). That's how clients grow the standard in unintended ways, no?
On another note:
3. optionally, the trailer field section, if present, sent as a single HEADERS frame.
I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume.
I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.
On another note:
I see you're paving the way for gRPC on the Web (of browsers) by adding trailers (a header sent after the body), which is not supported today for HTTP/1 not /2 by at least the top 3 browser vendors in volume.I'm divided: I'd be glad to get rid of grpc-gateway and websockets but isn't proto-encoded communication bad for the open Web /in principle/? Maybe it's only a tooling problem.