-
Notifications
You must be signed in to change notification settings - Fork 435
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
grpc.WrappedGrpcServer.ServerHTTP() returns response with invalid Content-Type header #334
Comments
This seems like a regression to me, last time I ran my interop tests all the requests from a grpc/grpc-web client worked with the |
Thanks for the prompt reply! https://github.com/johanbrandhorst/grpc-web-compatibility-test repository has slightly different set up as it uses My assumption (and it's only assumption at this stage based on my superficial review of |
Very interesting analysis! I guess the next question is, why wouldn't the |
I was able to reproduce this in the compatibility tests by adding an in-process proxy. Very interesting. Definitely need more investigation. Have you got any closer to figuring out where the problem is? Should the gRPC |
I was running the code in debugger to see where the possible problem. I can confirm on my end that gRPC service sets the header correctly. However, the method WriteHeader in grpcWebResponse never gets called by the service. This is the method in grpcWebResponse that has header preparation logic for grpc-web side. I am planning to dig more on this. IMHO when used directly the underlying gRPC service behaves differently in respect to what it calls when writing the response. |
Very interesting, I'm also doing some debugging now that I have an easily reproducible scenario. I'll let you know if I find anything strange! |
Will do, thanks! |
Hmm, in my testing it looks like the content type is being written to the response body as an in-body trailer. Maybe that's what's causing the issue? Might need some extra handling in the wrapper. |
Yep, the difference is definitely that the |
Yeah, that's consistent with what i can see in my debugging. However in my case, the |
Indeed, but I think it's probably wrong to write it as a trailer at all. I think it's not converted because it's unexpected. I'll see if I can make some changes to the proxy to get it to write it as a proper header. |
Yeah absolutely it should not be in trailers :). There is definitely a need for some sanitisation before writing the trailers. Since |
Thanks your support! |
The more I look at this the more I think the way we're wrapping the |
That's sort of the feeling I am getting as well. In my experience I was placing a breakpoint on this line and the process never hit it. This is the case at least for the unary request, TBH I haven't tried server-side streaming. But it looks like gRPC service code does not differentiate between a unary request and the server-side stream, it just treats the response in unary request as a stream with a single chunk - I might be wrong. The gRPC service still calls Header() method to set up its headers directly. May be its worth using this method to place the headers straight into HTTP/1.1 response? And then separate trailing headers and substitute Trailing headers from gRPC service then might be separated in the process of header sanitisation and written into the body in exactly the same way they are written in |
That sounds like a good plan, I've got both unary and server streaming responses in my test cases so should be able to figure it out when I get the time. Feel free to play around with the compatibility tests yourself if you want an easy test case. |
Kind of related; #300 |
I've decided to try to reproduce this with the local proxy tests; that should make it easier to develop a solution. |
I've opened #339 with a failing test for this case. I don't have time to work on it right now or tomorrow but hopefully this can help your debugging and triaging efforts :). |
Thanks for all these tests, I will keep debugging and let you know if I find something else. |
When wrapping
grpc.Server
in typegrpc.WrappedGrpcServer
using packagegithub.com/improbable-eng/grpc-web/go/grpcweb
, the methodServeHTTP
does not set aContent-Type
header either toapplication/grpc-web-text
orapplication/grpc-web
. This causes a javascript client using protobuf generated files withhttps://github.com/grpc/grpc-web
package to skip processing the response from the gRPC server. As a result, a callback function on the request method or on streamdata
event are not getting called even though the entire request is completed successfully (in case of unary request) or ongoing (in case of server-side streaming).This behaviour of
grpc.WrappedGrpcServer
is manifested both when using a unary request and server-side streaming. Also the result is the same regardless of the mode the javascript files are generated with (grpcwebtext
orgrpcweb
).I am using the latest
https://github.com/grpc/grpc-web
library (1.0.3) and the latest version ofgithub.com/improbable-eng/grpc-web/go/grpcweb
packageThe text was updated successfully, but these errors were encountered: