Hello! On Tue, Jul 16, 2019 at 04:23:17PM -0400, bmacphee wrote:
> I appreciate the suggestion but it doesn't look like this is possible to > solve with these modules. The authentication part happens as a sub-request, > and the response provided by sub request influences how the gRPC part is > handled at the top level. Unless I can figure out some way to pass > variables from the sub request and handle things differently... I don't > know. > > If I return 200, the request proceeds as if it were authorized. This is > bad. The gRPC protocol fails to follow HTTP status code semantics, and all responses in gRPC use status code 200. For details see protocol specification here: https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md How a particular response will be handled by a client depends on the "grpc-status" response header. You can add one with the "add_header" nginx configuration directive. Note that it might be non-trivial to find out which grpc-status codes should be used, as the "specification" in question fails to define them. Status codes seems to be listed - and with some descriptions - here in the grpc sources: https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/status.h -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
