Today, these clients will receive an HTTP status 200 (OK) with a trailer that
gRPC clients would be able to interpret as an error, but non-gRPC clients would
interpret as a success. In Go and Java, this will have a grpc-status of
UNKNOWN due to an unexpected content-type header. In C, the content-type
header is currently ignored, but a grpc-status of UNAVAILABLE will be returned
if a handler for that method is not registered (which is likely in this
scenario).
This change updates the gRPC HTTP/2 spec to recommend returning HTTP status 400
(Bad Request) to interoperate better with non-gRPC clients.
Note that we should not do any enforcement on user-agent, as the spec
specifically says "the protocol does not require a user-agent to function".
I got this error on an unrelated patch, and I believe the Distribution
Test is broken:
/var/local/git/grpc/src/core/lib/security/credentials/jwt/jwt_verifier.cc:628:57: error: invalid conversion from 'const uint8_t* {aka const unsigned char*}' to 'unsigned char*' [-fpermissive]
GRPC_SLICE_LENGTH(signature)) != 1) {
^
In file included from /usr/include/openssl/pem.h:69:0,
from /var/local/git/grpc/src/core/lib/security/credentials/jwt/jwt_verifier.cc:35:
/usr/include/openssl/evp.h:642:5: note: initializing argument 2 of 'int EVP_DigestVerifyFinal(EVP_MD_CTX*, unsigned char*, size_t)'
int EVP_DigestVerifyFinal(EVP_MD_CTX *ctx, unsigned char *sig, size_t siglen);
There is usually 9 metadata in incoming headers. We are calling
arena_alloc for all of them and that accounts for 75% of the
calls to arena_alloc.
Simply preallocate 10 of them in the structure so that we can
avoid the atomic op, per header.
Users will not be affected, as MSBuild is not case-sensitive.
The changes in C# code are also entirely for consistency; they
do not affect the tooling dll at runtime.
Closes#17884
protoc and gRPC codegens differently treat non-ASCII letter
characters and symbols other than underscores when constructing
their respective output filenames for generated .cs files.
This change reproduces their respective behaviors exactly.
Fixes#17661
grpc_byte_buffer_reader_next() copies and references the slice. This
is not always necessary since the caller will not use the slice
after destroying the byte buffer.
A prominent example is the protobuf parser, which
calls grpc_byte_buffer_reader_next() and immediately unrefs the slice
after the call. This ref() and unref() calls can be very expensive
in the hot path.
This commit introduces grpc_byte_buffer_reader_peek() which
essentialy return a pointer to the slice in the buffer, i.e.,
no copies, and no refs.
QPS of 1MiB 1 Channel callback benchmark increases by 5%.
More importantly insructions per cycle is increased by 10%.
Also add tests and benchmarks for byte_buffer_reader_peek()
This commit reaplies 509e77a5a3