[contrib/net/http] add option to wrap a provided *http.ServeMux #2690
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There are many cases where the traced serve mux should be the 'outer' most http handler in a chain of wrapped handlers. For example, if one wanted to write a middleware which logged all requests by wrapping a http.Handler and they wanted this logger to log dd.trace_id and dd.span_id, that logger would have to execute after the traced http.Handler. One could achieve this using the contrib/net/http#WrapHandler function, but this loses the nice capability of naming the resource using the http.ServeMux#Handler method because the resourceNamer config does not have access to the mux itself. Another approach, would be to have the contrib/net/http.ServeMux take another ServeMux as an option, and use that as its mux if provided. This way, the first 'handler' in a chain of request handlers would be the contrib/net/http.ServeMux. This traced mux would add trace context to the http request. This traced request would then be passed to the e.g. logging middleare mux, and so on, and so forth.
|
This PR is stale because it has been open 20 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
Hi @powerbill, thanks for opening a PR and sorry for the delayed response. |
|
This PR is stale because it has been open 20 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
This PR is stale because it has been open 20 days with no activity. Remove stale label or comment or this will be closed in 10 days. |
|
This PR was closed because it has been open for 30 days with no activity. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are many cases where the traced serve mux should be the 'outer' most http handler in a chain of wrapped handlers. For example, if one wanted to write a middleware which logged all requests by wrapping a http.Handler and they wanted this logger to log dd.trace_id and dd.span_id, that logger would have to execute after the traced http.Handler. One could achieve this using the
contrib/net/http#WrapHandler function, but this loses the nice capability of naming the resource using the http.ServeMux#Handler method because the resourceNamer config does not have access to the mux itself.
Another approach, would be to have the contrib/net/http.ServeMux take another ServeMux as an option, and use that as its mux if provided. This way, the first 'handler' in a chain of request handlers would be the contrib/net/http.ServeMux. This traced mux would add trace context to the http request. This traced request would then be passed to the e.g. logging middleare mux, and so on, and so forth.
What does this PR do?
Motivation
Reviewer's Checklist
Unsure? Have a question? Request a review!