RealGrpcCall/GrpcClient configurability for grpc-accept-encoding and grpc-encoding
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 4.4k
- Forks
- 627
- Avg merge
- 3d 15m
- Merged PRs (30d)
- 20
Description
Hello, I am currently using wire to talk to a back end grpc service which does not support any compression for requests/responses.
I did some spelunking to figure out if I can configure or work around this issue but it looks like the RealGrpcCall set the request encoding to be gzip always. Additionally, the GrpcClient also sets the headers grpc-accept-encoding and grpc-encoding to be gzip as well.
Are there immediate plans (or even ideas) on making this configurable?
I'm also happy to propose change (and help) for this but from a glance at the code, it seems like a little intrusive and non-trivial of a change (I still am happy to collaborate!)
Thank you,
Alan
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with wire-library/wire-grpc-client/src/jvmMain/kotlin/com/squareup/wire/internal/grpc.kt at RealGrpcCall and GrpcClient.kt around lines 69-70. Trace where gzip is assigned to the request encoding and grpc-accept-encoding/grpc-encoding headers, then inspect nearby client configuration patterns. Done means callers can configure or disable these compression settings while existing behavior remains covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- grpc, kotlin
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100