Browser Clients and Trailers

## The problem gRPC-Web solves gRPC is defined over HTTP/2, and a native call depends on two things page script in a browser does not have. The first is the framing layer. The native protocol assumes the caller can drive HTTP/2 streams directly, and browser networking APIs deliberately hide that layer - script hands over a request and receives a response, and the connection underneath is the browser's business. The second is decisive: **trailing metadata**. Native gRPC announces a call's outcome *after* the response body, in a trailer section - a block of header fields sent at the end of the message rather than at the front. The browser's networking APIs surface response headers to script; they do not surface trailing fields. A call whose success or failure is announced only in trailers is, from the page's point of view, a call with no outcome at all. gRPC-Web is a **separate wire protocol for the same calls**, defined so that everything it needs is something an ordinary HTTP client already has: a request with a body, a response with a body, and headers at the front. ## What the variant changes - The call is an ordinary HTTP request: `POST`, a path built from the service and method, and the encoded request message in the body. - **The trailing status moves into the response body** as a final frame, so the outcome arrives as payload bytes the page can read rather than as trailing header fields it cannot. - **The response ends when the body ends.** No protocol frame closes it. - Nothing in the variant depends on HTTP/2 framing, so it also runs over HTTP/1.1 - and it therefore gives up the signals HTTP/2 framing would have carried: stream identifiers, a connection-closing frame, transport pings. - The client identifies itself in a field of the variant's own, `X-User-Agent` (for example `X-User-Agent: grpc-web-javascript/0.1`), because `user-agent` belongs to the browser and script cannot set it. - Two of the four call shapes do not survive. A browser client gets **unary** and **server-streaming**; **client-streaming** and **bidirectional streaming** are not available. ## The media types | Value | What it means | |---|---| | `application/grpc-web` | The variant with no message-format suffix; a receiver treats it as `+proto` | | `application/grpc-web+proto` | The variant, messages encoded with Protocol Buffers - the ordinary case | | `application/grpc-web-text` | The same protocol with the whole body base64-encoded, for environments that cannot carry binary bodies | A client asks for the text form with `Accept: application/grpc-web-text`. Note what is *not* here: the variant defines no cross-origin field names of its own. A browser's usual cross-origin rules apply to a gRPC-Web request exactly as they apply to any other request, and nothing in the protocol changes or replaces them. ## Where the translation happens The expected deployment is a **translating intermediary** sitting between the browser and a service that speaks native gRPC. In one direction it takes the gRPC-Web request and re-frames it as a native call; in the other it takes the native response, lifts the trailing status out of the trailer section and writes it back into the response body as the final frame. A server framework may instead implement the variant itself and serve both protocols on the same port - either way, *something* performs that translation, because a service that only speaks the native protocol will not accept a gRPC-Web request unchanged. One consequence is worth internalising early: the HTTP status of a gRPC-Web response is not the call's outcome. A response can carry an ordinary success status line and still describe a failed call, because the real status is in the trailer frame at the end of the body. ## What an interviewer is checking 1. Do you know that the browser limitation is about **trailing metadata and framing**, not about TLS, ports or performance? 2. Do you know that gRPC-Web is a **different wire protocol**, not gRPC with a flag flipped - so something in the path has to translate? 3. Do you know **what it costs**: two call shapes, and a stream whose end is the end of a body rather than a protocol event? A candidate who answers "the browser just can't do HTTP/2" is close but has the wrong mechanism - browsers speak HTTP/2 constantly. What they do not do is hand script the controls, or the trailers.