Why do people say gRPC doesn't work over HTTP/1.1?

[James Roper]

I don't understand why people say gRPC doesn't work over HTTP/1.1.

Many people say that gRPC is dependent on HTTP/2 framing, but this is completely incorrect. gRPC has it's own message framing protocol that can sit on top of any protocol that allows full duplex streaming of binary data. It sits on top of HTTP/2 framing without being dependent on any of the features of HTTP/2 framing at all.

The next reason given is usually that HTTP/1.1 does not support full duplex streaming. But that's not correct. HTTP/1.1 is currently specified in RFC9112. There is nothing in there saying that a request body and response body can't be concurrently sent by the client and the server. RFC2616 even made explicit that the server sending a response while the client was still sending it's request body was possible in section 8.2.3:

If an origin server receives a request that does not include an Expect request-header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final status code before reading the entire request body from the transport connection, then the server SHOULD NOT close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, the client might not reliably receive the response message.

I have also heard it argued that semantically, HTTP/1.1 doesn't support full duplex communication, and that's the problem, because the semantics of HTTP are that an HTTP response message is sent in response to an HTTP request message, which includes both its headers and body. But HTTP/1.1 and HTTP/2 have exactly the same semantics, which are specified by RFC9110. An earlier version of the HTTP/2 spec even explicitly stated that the semantics of HTTP/1.1 remain unchanged in HTTP/2. So if HTTP/1.1 doesn't support full duplex communication semantically, then neither does HTTP/2, and therefore gRPC can't work, semantically at least, on HTTP/2. Maybe this is true, but that's an argument to be had between the creators of gRPC and the authors of the RFC9110 spec. Regardless, if gRPC is allowed to ignore HTTP semantics in order to work on HTTP/2, then it's allowed to ignore those same HTTP semantics to work on HTTP/1.1. 

As far as implementations go, gRPC works over HTTP/1.1 between clients and servers that support it, as long as both the client and the server are using chunked encoding, and are using asynchronous IO. An example of a gRPC implementation where this works with no problems is akka-grpc. There is nothing HTTP/2 specific about the code in akka-grpc. You can use either akka-http's HTTP/1.1 or HTTP/2 support underneath, and both work for both unary and streamed requests. The client writes the request header with chunked transfer encoding specified, the server immediately writes the response header, also with chunked transfer encoding specified, and then both client and server can communicate their request and response bodies simultaneously, allowing full duplex gRPC streaming. When the server finishes, it sends the gRPC status message in the last chunk trailer.

In practice however, there are big problems, especially when proxies are involved. Many HTTP/1.1 clients, servers and proxies are implemented using a thread per request model with blocking IO, making full duplex communication impossible, as they can only read from one direction at a time. Furthermore, many HTTP client and server implementations don't expose the necessary APIs to implement gRPC over HTTP/1.1, such as chucked encoding trailer support. And some implementations that do support asynchronous IO don't provide any means, via their APIs, to send a response before the request body has been read, or to read the response before the request body has been fully sent.

HTTP/2 on the other hand, due to its multiplexing capabilities, can only be feasibly implemented using non blocking IO, which makes full duplex streaming not only possible, but easier to support than half duplex. As a result, many of the issues with doing gRPC over HTTP/1.1 disappear when using HTTP/2. This does mean that it makes sense to say that gRPC should only use HTTP/2, however, it doesn't mean that it cannot work on HTTP/1.1 if due to prior knowledge, you know that the full network path supports it.

The upshot of all this is you should never do gRPC over HTTP/1.1 over networks and with client, server and proxy implementations that you are not in complete control of, such as over Internet. But for internal communication in data centres, where you control your exact network topology, and you control the client, server and any proxy server that may be in the communication path, there's no reason why gRPC can't work over HTTP/1.1. So, why say it doesn't?

[Eric Anderson]

On Fri, Jan 23, 2026 at 6:49 AM James Roper <jro...@gmail.com> wrote:

I don't understand why people say gRPC doesn't work over HTTP/1.1.

Take a look at an old response of mine on this list: https://groups.google.com/g/grpc-io/c/Jk6-E3Ezb2g/m/mhimOU7RHksJ . You are correct that the gRPC protocol only needs HTTP/1.1 semantics.

The upshot of all this is you should never do gRPC over HTTP/1.1 over networks and with client, server and proxy implementations that you are not in complete control of, such as over Internet. But for internal communication in data centres, where you control your exact network topology, and you control the client, server and any proxy server that may be in the communication path, there's no reason why gRPC can't work over HTTP/1.1. So, why say it doesn't?

If you have such control over the environment, why use HTTP/1.1 instead of HTTP/2? It is essentially the "same" work to make sure HTTP/2 works as it is to make sure HTTP/1.1 works. It is definitely true that our gRPC implementations don't support HTTP/1.1, so it literally doesn't work. If you have some reason you want HTTP/1.1, then you probably also have one of those implementation limitations that prevents it from working well.

I'll note also that we generally design for encrypted connections (TLS); that makes HTTP/1.1 much more expensive.