Add the "grpc-encoding" header to the response #20
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Once the per-message compression encoding has been negotiated (by inspecting the `grpc-accept-encoding` request header), the server should tell the client the chosen encoding (either `identity` or `gzip`) by setting the `grpc-encoding` response header. The meaning of the header is: if any message in the response has its compression flag set, then that message has been compressed using this encoding. Some clients can live with the header being missing. If they encounter a message with its compression flag set, they just assume the encoding is GZip. But other clients, notably the official Java gRPC library, are stricter and require the header to be present. Aside: compression can be done at the stream level rather than the individual message level. In that case, the `content-encoding` header must be set, and the `grpc-encoding` header must *not* be set. None of this is really documented anywhere. I worked it out using Wireshark and reading the [grpc-java source](https://github.com/grpc/grpc-java/blob/8d4240f4800f20de0e5f0b7c213577b3c0324f93/core/src/main/java/io/grpc/internal/AbstractClientStream.java#L313-L356).
cb372
commented
Mar 21, 2020
| putStrLn "running handler" | ||
| _ <- handler pickedDecompression pickedCompression req write flush | ||
| _ <- handler (pickedDecompression req) (pickedCompression req) req write flush | ||
| putStrLn "setting GRPC status" |
There was a problem hiding this comment.
Do you mind if I delete these putStrLns while I’m here?
There was a problem hiding this comment.
Please do so, I think they should not be there in any case
|
Thanks for the PR! I've just release version 0.4.0.1 with this fix 😄 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Once the per-message compression encoding has been negotiated (by
inspecting the
grpc-accept-encodingrequest header), the server shouldtell the client the chosen encoding (either
identityorgzip) bysetting the
grpc-encodingresponse header.The meaning of the header is: if any message in the response has its
compression flag set, then that message has been compressed using this
encoding.
Some clients can live with the header being missing. If they encounter a
message with its compression flag set, they just assume the encoding is
GZip. But other clients, notably the official Java gRPC library, are
stricter and require the header to be present.
Aside: compression can be done at the stream level rather than the
individual message level. In that case, the
content-encodingheadermust be set, and the
grpc-encodingheader must not be set.None of this is really documented anywhere. I worked it out using
Wireshark and reading the grpc-java source.