Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

First-class HTTP header support #23

Merged
merged 5 commits into from
Mar 8, 2018
Merged

First-class HTTP header support #23

merged 5 commits into from
Mar 8, 2018

Conversation

Xorlev
Copy link
Owner

@Xorlev Xorlev commented Mar 7, 2018

First-class HTTP header support. HTTP request headers are read into and attached to the gRPC Context. Likewise, response headers can be controlled from within your RPC handler.

This works by capturing the HTTP request headers from Jersey. These headers are given to a gRPC ClientInterceptor which translates these headers into a protocol buffer message (imaginatively named Headers). This message is then attached as a Metadata key and sent along with the underlying RPC.

A ServerInterceptor extracts this protocol buffer message and writes the headers into the current gRPC Context (smart thread-local state).

The RPC handler can read the headers (separate from the headers being splatted into the Metadata, as is the unfortunate default of the "proxy" mode) and do what it wants with them. ServerInterceptors that run after the HttpHeaderServerInterceptor can also work with these headers (e.g. extract OAuth tokens, JWT, etc.) to transform those headers into whatever Metadata or Context attachment you like.

All headers are available inside the HttpHeaderContext, a static utility for working with Context-local state. HttpHeaderContext.requestHeaders() gives access to the request headers, and there's various setter/clear methods for response headers, e.x. HttpHeaderContext.setResponseHeader("X-Hello", "World"). Likewise, ServerInterceptors running before the HttpHeaderServerInterceptor can also set headers. And, just like before, these headers are bundled up into the Headers proto and sent to the client (usually in-process) to be set on the outgoing HTTP response.

TODO:

  • Stabilize integration tests. GrizzlyWebTestContainerFactory seems to have some behavioral differences that aren't deterministic -- a test will fail. Run that one test, it works. The streaming tests don't work at all, despite working via manual testing with the ProxyIntegrationApp.
  • Update ServerStub tests to not check HTTP features.
  • Return headers on a best-effort basis from RPC errors.

Now uses JAX-RS base AsyncContext, making it much easier to add headers
to the response before streaming begins.
@Xorlev Xorlev changed the title First-class HTTP header support First-class HTTP header support, fixes #22 Mar 7, 2018
@Xorlev Xorlev changed the title First-class HTTP header support, fixes #22 First-class HTTP header support Mar 7, 2018
First-class HTTP header support. HTTP request headers are read into
and attached to the gRPC Context. Likewise, response headers can be
controlled from within RPC handlers.

Notable other changes:
 - Switches the Grizzly2 as a test provider, for @context injection.
 - Addition of GrpcJerseyPlatformInterceptors, a utility which will be
   used to automatically add interceptors for future behavior.

Resolves #22
Headers are now sent on error, allowing users to send diagnostic headers
if desired, or just to maintain consistency (e.g. X-Frontend:
gRPC-over-HTTP kind of headers) or similar.
@Xorlev
Copy link
Owner Author

Xorlev commented Mar 8, 2018

FYI @smartwjw

@Xorlev Xorlev merged commit 72aed1e into master Mar 8, 2018
@Xorlev Xorlev deleted the headers branch March 8, 2018 03:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant