The GRPC client interface allows an optional map of "metadata" name/value pairs, sent as HTTP headers, to be
specified. This is useful for things like authorization, allowing the caller to set access tokens etc.
There are two types of metadata: per-connection and per-call. Currently, both of these are simple maps that
are merged together for any given request.
The problem with per-connection metadata is that connections may be held open for long periods of time, and this
has the potential to allow information contained in the per-connection metadata to go stale. For example,
a JSON Web Token set in an "Authorization" header may expire on a shorter horizon than the connection.
This patch enhances this by allowing the per-connection metadata to be specified as an optional 0-arity
fn that returns a metadata map. This way, we remain backwards compatible with existing applications that
use the static per-connection metadata, while allowing new clients to provide a means to refresh the
metadata on whatever interval suits their needs.
For instance, a metadata function could be written such that it handles JWT acquisition, caching, and just-in-time
token refresh transparently to protojure.
The GRPC client interface allows an optional map of "metadata" name/value pairs, sent as HTTP headers, to be specified. This is useful for things like authorization, allowing the caller to set access tokens etc.
There are two types of metadata: per-connection and per-call. Currently, both of these are simple maps that are merged together for any given request.
The problem with per-connection metadata is that connections may be held open for long periods of time, and this has the potential to allow information contained in the per-connection metadata to go stale. For example, a JSON Web Token set in an "Authorization" header may expire on a shorter horizon than the connection.
This patch enhances this by allowing the per-connection metadata to be specified as an optional 0-arity fn that returns a metadata map. This way, we remain backwards compatible with existing applications that use the static per-connection metadata, while allowing new clients to provide a means to refresh the metadata on whatever interval suits their needs.
For instance, a metadata function could be written such that it handles JWT acquisition, caching, and just-in-time token refresh transparently to protojure.
Signed-off-by: Greg Haskins greg@manetu.com