Support http request header passing #22
Comments
m11y
changed the title
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
|
Good news, this was already on my list of things to do. Support for this should land in the next day or two. |
|
@smartwjw When you have a chance to take it for a spin, I'd love your feedback on it and whether there's any rough edges you encounter. It's not too late to change the API in 0.4.0. |
|
@Xorlev Thanks, I will try it soon. |
|
@Xorlev Thanks a lot for doing this, but I just wonder why not just pass all the response headers from In my situation, I have a It will be great that |
|
I don't believe that these should be mixed: it makes it more complicated
especially in this situation given:
1) There will be headers set on the RPC response that aren't
ASCII-serializable.
2) There may be headers set on your internal RPCs that you may not want
exposed externally, especially diagnostic information.
3) This is a proxied system. The reason you had two User-Agent headers is
because there are two user agents: the User-Agent of the user hitting the
HTTP endpoint and the User-Agent of the proxy client calling the (in
process) RPC server.
I could say "anything prefixed with "grpc-http-" will be passed through,
but again, I think this solution is more deliberate and understandable.
…On Mon, Mar 12, 2018 at 5:18 AM, Junwei Wang ***@***.***> wrote:
@Xorlev <https://github.com/xorlev> Thanks a lot for doing this, but I
just wonder why not just pass all the response header from grpc directly,
just like the passing behaivor for request headers?
In my situation, I have a RequestIdInterceptor to generator request id
for every request, and If I want to pass generated header to client, I will
have to set it twice, once for grpc and another for grpc-jersey custom
header, thus caused code duplicate.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAVRyhiEPsdg7WIM5RCML8B_C7WtqmAiks5tdlmjgaJpZM4Sa1W_>
.
|
|
Thinking about it a bit more, should you want this behavior it'd be
reasonably easy to develop yourself. If you were to build a
ServerInterceptor to copy headers from the Metadata (take care to handle
both headers and trailers) into the HttpHeaderContext you'd have the
semantics you desire. I would recommend a whitelist of Metadata keys to
prevent unintentionally leaking headers.
…On Mon, Mar 12, 2018, 6:43 PM Michael Rose ***@***.***> wrote:
I don't believe that these should be mixed: it makes it more complicated
especially in this situation given:
1) There will be headers set on the RPC response that aren't
ASCII-serializable.
2) There may be headers set on your internal RPCs that you may not want
exposed externally, especially diagnostic information.
3) This is a proxied system. The reason you had two User-Agent headers is
because there are two user agents: the User-Agent of the user hitting the
HTTP endpoint and the User-Agent of the proxy client calling the (in
process) RPC server.
I could say "anything prefixed with "grpc-http-" will be passed through,
but again, I think this solution is more deliberate and understandable.
On Mon, Mar 12, 2018 at 5:18 AM, Junwei Wang ***@***.***>
wrote:
> @Xorlev <https://github.com/xorlev> Thanks a lot for doing this, but I
> just wonder why not just pass all the response header from grpc
> directly, just like the passing behaivor for request headers?
>
> In my situation, I have a RequestIdInterceptor to generator request id
> for every request, and If I want to pass generated header to client, I will
> have to set it twice, once for grpc and another for grpc-jersey custom
> header, thus caused code duplicate.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#22 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAVRyhiEPsdg7WIM5RCML8B_C7WtqmAiks5tdlmjgaJpZM4Sa1W_>
> .
>
|
In my opinion, gRPC is built upon http2, since most header should be ASCII-serializable(we didn't use any header that isn't ASCII-serializable), especially API for mobile app and web browser. The reason I choose By the way, we put an
The library may expose some method to set whitelist or backlist headers names.
User-Agent double passing is not a big problem, I can handle to easily, it ok for me now.
I will give it a try. However, I will suggest that the library supplies the abilities to pass header in both ways, the developers use it at his own discretion. |
gRPC might be, but grpc-jersey is likely not running on a HTTP/2 native server. grpc-jersey is really a browser-compatible HTTP/1.x<->gRPC translation layer.
It's a fair point. All headers are actually ASCII encoded (base64'd) during translation to HTTP/2 (but they're renamed, e.x.
Yes, it could. Again, I'd rather it be an interceptor that can be layered in if desired. Keep in mind, if you went down this route, you may also need per-method whitelists as your needs may be different based on each RPC.
If you develop an interceptor that does this, I certainly wouldn't turn down a pull request. At the moment I don't have any available time to work on it. |
user-agentheader is duplicated.The text was updated successfully, but these errors were encountered: