-
Notifications
You must be signed in to change notification settings - Fork 115
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
requestID middleware should entertain X-Request-ID
along with Request-ID
#170
Comments
It will be easier to modify the nginx config to accept |
@chinmayb, @kd7lxl, this was investigated previously and there is a document on how to populate Request Id At Nginx level.
Headers that come from REST need to be translated to gRPC metadata. This is done by DefaultHeaderMatcher. The problem here is that headers like Following the Request Id At Nginx level doc we will be able to populate |
Request-ID is not a standard or commonly used HTTP header. Toolkit should support the very common header X-Request-ID. This ID is not just for nginx, it's used by many proxies and middleware logging applications to trace requests through server stacks. We do not want to modify every possible middleware to support our non-standard Header which most likely will break future applications when a Request-ID standard is defined. We should deprecate, but continue to support Request-ID while adding support and updating documentation for X-Request-ID. At the next major release, we can remove support for Request-ID. https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Common_non-standard_response_fields |
Fixed in #197 |
Currently NGINX controller accepts
X-Request-ID
and auto generates an ID . Internal components who use requestID middleware looks forRequest-ID
. So the nginx requestID gets lost and new requestID gets propagated.Proposals
Request-ID
headeror
X-Request-ID
or both.The text was updated successfully, but these errors were encountered: