What does a gRPC call look like as an HTTP/2 request, and how does the server know which method is wanted?

## One POST per call gRPC does not invent a transport. A call is an ordinary **HTTP/2 request**: the client opens one stream, sends a `HEADERS` frame, then `DATA` frames holding the request messages, then closes its direction. Because the request shape is plain HTTP/2, anything that speaks HTTP/2 — a reverse proxy, an L7 load balancer, a packet capture — sees the call, which is exactly why this leaf matters: the parts that are *not* ordinary HTTP are the parts an intermediary can ruin. The method is **always POST**. There is no read-versus-write distinction on the wire, no `GET` for a lookup, and no way for an rpc declaration to choose something else. A cache keyed on HTTP method semantics therefore sees every call as unsafe and non-idempotent, which is the correct reading of it. ## The pseudo-header block Four pseudo-headers open the request: - **`:method`** — `POST`, without exception. - **`:scheme`** — `http` or `https`, following whether the connection is protected. - **`:authority`** — the host the caller believes it is talking to; an in-path hop that rewrites it changes which virtual service answers. - **`:path`** — the routing key for the whole call, described next. ## Naming the method in the path The specification builds the path from two names the schema already defines: 1. **Service-Name** is `{proto package name}` `"."` `{service name}` — so a `DeclarationService` declared in package `customs.v1` is `customs.v1.DeclarationService`. 2. The path is `"/"` + Service-Name + `"/"` + the **method name** exactly as the schema spells it. So a broker filing a declaration sends `:path = /customs.v1.DeclarationService/SubmitDeclaration`. This is the single most useful fact about the request shape in operations: an intermediary can route, rate-limit, authorise or log per method **without decoding a single message**, because the method identity is in a plain-text path. It is also why a route pattern written for a resource-oriented API — `/declarations/{id}` — never matches: gRPC paths are not resource paths, and the declaration's identifier is a field inside the request message, not a path segment. ## The call-definition fields Beside the pseudo-headers sit fields the specification defines for the call itself, distinct from any application metadata the caller attaches: | field | sent by | what it does | |---|---|---| | `content-type` | client | `application/grpc`, optionally `application/grpc+proto` or `application/grpc+json`, naming the message encoding | | `te` | client | the value `trailers`, announcing the client accepts a trailing status | | `grpc-encoding` | client | the per-message compression applied to messages in this request | | `grpc-accept-encoding` | client | the per-message compressions the client can decode in the response | | `user-agent` | client | identifies the calling implementation | Header field names are lowercase and drawn from a restricted charset (`0-9`, `a-z`, `_`, `-`, `.`), and the specification suggests an **8 KiB** default limit on the whole request header block, enforceable with `SETTINGS_MAX_HEADER_LIST_SIZE`. A caller that stuffs a large token or a long correlation value into metadata can exceed it, and the call fails before the server sees a byte of the message. ## Why `te: trailers` is there at all On HTTP/1.1 the `TE` field was how a client announced it would accept trailing fields after a chunked body. HTTP/2 needs no such negotiation — trailing fields are just another `HEADERS` frame. gRPC keeps the field anyway as a **tripwire**: the outcome of every call travels in the trailer section, so an intermediary too old to forward one is a fatal hop, and requiring the field on every request gives such a hop something it can recognise and refuse rather than silently swallow. ## What the server checks before anything else 1. **Content type.** If it does not begin with `application/grpc`, the server answers `415 (Unsupported Media Type)`. This is an HTTP-level rejection: there is no gRPC status because there is no gRPC call yet. 2. **Path.** An unrecognised service or method is a normal gRPC failure, answered with a status in the trailing metadata rather than an HTTP error. 3. **Message framing.** Everything after the header block is read as length-prefixed messages, never as a raw body. The practical consequence for a cross-border filing gateway is that the two failure classes look completely different on the wire: a misconfigured client gets an HTTP-shaped rejection it can read with any tool, while a real application failure gets a 200 response whose outcome is hidden in trailing metadata — the subject of the next question.