This is in preparation for preventing any user-supplied metadata starting with "grpc-", which is reserved.
* stats: add methods to allow setting grpc-trace-bin and grpc-tags-bin headers
Pick these up in grpc's transport when sending and fill them when receiving.
* Add tags/trace to metadata and tests for that behavior
This is temporary to maintain compatibility and provide a migration strategy.
- All logs use 1 severity level instead of printf
- All transport logs only go to verbose level 2+
- The default logger only log errors and verbosity level 1
- Add environment variable GRPC_GO_LOG_SEVERITY_LEVEL and GRPC_GO_LOG_VERBOSITY_LEVEL to set severity or verbosity levels for the default logger
This change ensures consistency for the user when accessing metadata values:
they are never encoded except when sent on the wire. Previously, they would
appear encoded to client code, but not to server code. As such, this
represents a behavior change, but one unlikely to affect user code, as it's
unusual to inspect the metadata after setting it.
When an error implemented by the status package is returned from a service
handler, the server will transmit a rich status message in the
"grpc-status-details-bin" trailing metadata field if any detailed data is
attached to the error. Client-side, we will decode them if present in the
server's response and return them to the user code performing the RPC.
This is backward compatible with the existing errors supported by the grpc
package. However, the grpc.Errorf, grpc.Code and grpc.ErrorDesc functions for
managing errors are now deprecated; status.Errorf and status.Status type
asserions should be used instead.
The Framer now has support for merging HEADERS+CONTINUATION frames.
This remove the frame merging & hpack state machine from grpc.
In addition to being more compliant with the spec, this also means
gRPC enforces the header list size, removing a DoS vector.
Change-Id: Id46a6a1e741e62a859c3e3fb9f0cc36febf1d836
The http.Handler-based transport body reader was returning error types
not understood by the recvMsg parser. See #557 for some background and
examples.
Fix the http.Handler transport and add tests. I copied in a subset of
the http2 package's serverTest type, adapted slightly to work with
grpc. In the process of adding tests, I discovered that
ErrUnexpectedEOF was also not handled by the regular server
transport. Document the rules and fix that crash as well.
Unrelated stuff in this CL:
* make tests listen on localhost:0 instead of :0, to avoid Mac firewall
pop-up dialogs.
* rename parser.s field to parser.r, to be more idiomatic that it's an
io.Reader and not anything fancier. (it's not acting like type
stream, even if that's the typical concrete type)
* move 5 byte temp buffer into parser, rather than allocating it for
each new message. (drop in the bucket improvement in garbage; more
to do later)
* rename http2RSTErrConvTab to http2ErrConvTab, per Qi's earlier
CL. Also add the HTTP/1.1-required error mapping for completeness,
not that it should ever arise with gRPC, also per Qi's earlier CL
referenced in #557.
The grpc-http2 transport doesn't validate hpack-decoded field names to be
valid http2 field names before checking their first byte. Had it verified
first and found that the empty string is illegal, this crash wouldn't happen,
but currently a malicious request can crash a gRPC server by sending an empty
hpack string.
mmukhi
dfawley
Menghan Li
Jan Tattermusch
apolcyn
Qi Zhao
Michal Witkowski
Peter Edge
Peter Mattis
Brad Fitzpatrick
David Symonds
yangzhouhan