Use the Gin context when doing WrapF or WrapH #3368
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.
Because the signature of an
http.Handler
does not include a*gin.Context
, anhttp.Handler
can only accessreq.Context()
. However, this always refers to the request's original context instead of the Gin context. This means that any values set with Gin'sc.Set
are not accessible in those handlers. This means that Gin middleware that sets context values actually can't pass values to third-party handlers!This PR updates
WrapF
andWrapH
to makereq.Context()
return the Gin context itself. This makes calls likec.Value
work as expected.c.Request
is unaffected by this change, meaning that the original request (with its original context) can still be accessed viareq.Context().(*gin.Context).Request
if absolutely necessary. This also means thatContextWithFallback
still works. As far as I can tell, the only instance of breakage here would be:ContextWithFallback
, andAnd in this case, their problems could likely be fixed simply by opting into
ContextWithFallback
, rendering the breakage trivial.