3 ms·

If the browser folk had ever made HTTP Push available for use to the web page, such that actual grpc could run, I'd agree. gRPC/the web are at an impasse versus

If the browser folk had ever made HTTP Push available for use to the web page, such that actual grpc could run, I'd agree. gRPC/the web are at an impasse versus browsermakers who are resistant to new capabilities & who gave up on push as unsuccessful after never letting us try. Here's a good recent (4 year old) issue; it links back to much older issues. https://github.com/whatwg/fetch/issues/607 https://github.com/whatwg/fetch/issues/607 The rest of the protobuf world has gotten so much better. But the grpc on the web hacks feel bad. The awful option of running http3-over-webtransport-over-http3 is becoming alluring given the lack of browser care for the basics, and that's terrifying (it means the page loading & running it's own page/userland http3 stack). But there doesn't seem to be room for progress & innovation & even basic continuity/ways forward, with HTTP Push getting shoved out the airplane door. The work here to build yet another protocol that is gRPC like to workaround limitations is heroic. It's unfortunate that protocol development in general is hamstrung by these awkward longstanding limitations in the browser.

akshayshah 4y ago
From my limited perspective, it'd certainly be nice if browsers exposed more of HTTP. I also appreciate that the web platform is far larger, and far more backward-compatible, than any code I've ever even considered writing. If browser makers are slow to expose new protocol features, that's a cost I'm happy to pay. At least as I understand it, HTTP Push isn't the problem. The key problem is that browsers don't want to expose HTTP trailers. I understand their reluctance - even putting aside the security concerns, it's a huge semantic change. Many HTTP response headers, like etags, are typically computed by buffering the response, running some compute, then sending headers and the buffered body. All of those would, presumably, now need to also be sendable as trailers. What if the server sends both an etag header and trailer, and they don't match? The rabbit hole goes pretty far. Here's the Chromium issue where the gRPC and Chrome teams debate the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=691599 https://bugs.chromium.org/p/chromium/issues/detail?id=691599. There's also a series of whatwg issues about exposing trailers in the fetch API: https://github.com/whatwg/fetch/issues/34 https://github.com/whatwg/fetch/issues/34. For a protocol that sits above L7, the gRPC HTTP/2 protocol is liberal about diving past the semantics outlined in RFC 9110 and specifying transport-level details. (As an example, trailers-only responses must be sent in a _single_ HTTP/2 headers frame with the EOS bit set.) That degree of specificity unlocks some performance gains, but it makes it near-impossible to speak this protocol using an existing HTTP library - a traditional strength of building on top of L7. For broad adoption in a _lot_ of environments, gRPC-Web (and Connect) are IMO much better protocols.

akshayshah 4y ago

From my limited perspective, it'd certainly be nice if browsers exposed more of HTTP. I also appreciate that the web platform is far larger, and far more backward-compatible, than any code I've ever even considered writing. If browser makers are slow to expose new protocol features, that's a cost I'm happy to pay. At least as I understand it, HTTP Push isn't the problem. The key problem is that browsers don't want to expose HTTP trailers. I understand their reluctance - even putting aside the security concerns, it's a huge semantic change. Many HTTP response headers, like etags, are typically computed by buffering the response, running some compute, then sending headers and the buffered body. All of those would, presumably, now need to also be sendable as trailers. What if the server sends both an etag header and trailer, and they don't match? The rabbit hole goes pretty far. Here's the Chromium issue where the gRPC and Chrome teams debate the issue: https://bugs.chromium.org/p/chromium/issues/detail?id=691599 https://bugs.chromium.org/p/chromium/issues/detail?id=691599. There's also a series of whatwg issues about exposing trailers in the fetch API: https://github.com/whatwg/fetch/issues/34 https://github.com/whatwg/fetch/issues/34. For a protocol that sits above L7, the gRPC HTTP/2 protocol is liberal about diving past the semantics outlined in RFC 9110 and specifying transport-level details. (As an example, trailers-only responses must be sent in a _single_ HTTP/2 headers frame with the EOS bit set.) That degree of specificity unlocks some performance gains, but it makes it near-impossible to speak this protocol using an existing HTTP library - a traditional strength of building on top of L7. For broad adoption in a _lot_ of environments, gRPC-Web (and Connect) are IMO much better protocols.