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