Read a response's headers and trailers
A gRPC response has three parts: headers sent before the first message, the messages, and trailers sent with the final status. In istek, switch the response pane from Response to Headers or Trailers. The count on each tab shows whether the server sent any, and failed calls keep theirs.
Updated
What you will find there
| Where | Typical entries |
|---|---|
| Headers | content-type, grpc-encoding, and service entries such as x-request-id or rate-limit counters |
| Trailers | grpc-status, grpc-message, grpc-status-details-bin with the rich error details, and anything the service adds at the end |
Entries the protocol itself sets — :status, content-type and every grpc- key — are drawn quieter, so the ones your service added stand out.
Failed calls
A server that rejects a call still sends trailers, and that is usually where it says why. istek keeps a failed call's headers and trailers alongside its error, so a permission_denied comes with the request id to quote in the bug report.
Streams
A stream's headers appear the moment the server sends them, which can be long before the first message on a slow or long-lived stream. Its trailers appear when the stream ends.
Copying
With Headers or Trailers showing, Copy puts them on the clipboard as name: value lines, in the order the server sent them, repeated keys included.
Compression
grpc-encoding in the headers tells you whether the server compressed its reply. istek reads gzip and deflate replies automatically. To compress your own requests, choose gzip or deflate under Settings ▸ Compress requests.