pr comments

pull/5641/head
David Garcia Quintas 9 years ago
parent 0f45cee9c8
commit 87e6770a18
  1. 40
      doc/compression.md

@ -41,13 +41,14 @@ of the request, including not performing any compression, regardless of channel
and RPC settings (for example, if compression would result in small or negative
gains).
A compressed message from a client with an algorithm unsupported by a server,
WILL result in an INVALID\_ARGUMENT error, alongside the receiving peer's
`grpc-accept-encoding` header specifying the algorithms it accepts. If an
INTERNAL error is returned from the server despite having used one of the
algorithms from the `grpc-accept-encoding h`eader, the cause MUST NOT be related
to compression. Data sent from a server compressed with an algorithm not
supported by the client will also result in an INTERNAL error.
When a message from a client compressed with an unsupported algorithm is
processed by a server, it WILL result in an INVALID\_ARGUMENT error. The server
will include in its response a `grpc-accept-encoding` header specifying the
algorithms it does accept. If an INTERNAL error is returned from the server
despite having used one of the algorithms from the `grpc-accept-encoding`
header, the cause MUST NOT be related to compression. Data sent from a server
compressed with an algorithm not supported by the client WILL result in an
INTERNAL error on the client side.
Note that a peer MAY choose to not disclose all the encodings it supports.
However, if it receives a message compressed in an undisclosed but supported
@ -67,16 +68,21 @@ cases.
### Compression Levels and Algorithms
We currently (as of July 2015) support _gzip_ and _deflate_ as algorithms (with
the possible future addition of snappy). In order to simplify the public API,
it's intended to abstract the algorithms as _compression levels_ (such as "low",
"medium", "high") that'd map to concrete algorithms and/or their settings (such
as "low" mapping to "gzip -3" and "high" mapping to "gzip -9"). However, we
can't presently (July 2015) implement said compression levels at the client side
without either a initial negotiation of capabilities or an automatic retry
mechanism. Therefore, compression levels are only supported at the server side,
which is aware of the client's capabilities by virtue of the incoming
Message-Accept-Encoding header.
The set of supported algorithm is implementation dependent. In order to simplify
the public API and to operate seamlessly across implementations (both in terms
of languages but also different version of the same one), we introduce the idea
of _compression levels_ (such as "low", "medium", "high").
Levels map to concrete algorithms and/or their settings (such as "low" mapping
to "gzip -3" and "high" mapping to "gzip -9") automatically depending on what a
peer is known to support. A server is always aware of what its clients support,
as clients disclose it in their Message-Accept-Encoding header as part of their
initial call. A client doesn't a priori (presently) know which algorithms a
server supports. This issue can be addressed with an initial negotiation of
capabilities or an automatic retry mechanism. These features will be implemented
in the future. Currently however, compression levels are only supported at the
server side, which is aware of the client's capabilities by virtue of the
incoming.
### Propagation to child RPCs

Loading…
Cancel
Save