问题描述
任何人都可以解释这段代码的用途吗?
// This demonstrates how to enrich and pass custom context keys.
// In this case,we cache the current responseWriter in context.
type customContextKey int8
const (
_ customContextKey = iota
ctxResponseWriter
)
// The middleware configuration is for the handler executors. These do not apply to the swagger.json document.
// The middleware executes after routing but before authentication,binding and validation
func setupMiddlewares(handler http.Handler) http.Handler {
ourFunc := func(w http.ResponseWriter,r *http.Request) {
rctx := context.WithValue(r.Context(),ctxResponseWriter,w)
handler.ServeHTTP(w,r.WithContext(rctx))
}
return http.HandlerFunc(ourFunc)
}
如何丰富和传递自定义上下文键?
解决方法
简而言之:这是将自定义中间件应用于您的 go-swagger 应用程序提供的所有路由。该中间件将 ResponseWriter
添加为请求上下文中的自定义值。当然,这与 OAuth 无关。
循序渐进:
context
是一种特殊类型,可以跨代码层携带请求范围的值、截止日期和取消信号。
type customContextKey int8
这里我们定义了一个未导出的上下文键类型。我们这样做的原因是,当我们将值添加到上下文时,我们希望该值不会与其他可能与上下文交互的包设置的值发生冲突。例如,如果我们只使用字符串“customContextKey”而其他一些包碰巧使用相同的字符串,则可能会发生这种情况。更多信息here。
const (
_ customContextKey = iota
ctxResponseWriter
)
这里我们创建了一个名为 customContextKey
的 ctxResponseWriter
值,值为 1。注意我们忽略了 (_
) iota
的第一个值,它是0,而是使用下一个值 1。这是用于在上下文中存储实际 ResponseWriter
值的类型安全键。
中间件是采用 http.Handler
并返回 http.Handler
的函数,它们可以组合在一起,是一种以通用方式向应用程序处理程序添加额外功能的模式。如需更深入的了解,请查看 Making and Using HTTP Middleware。
func setupMiddlewares(handler http.Handler) http.Handler {
ourFunc := func(w http.ResponseWriter,r *http.Request) {
rctx := context.WithValue(r.Context(),ctxResponseWriter,w)
handler.ServeHTTP(w,r.WithContext(rctx))
}
return http.HandlerFunc(ourFunc)
}
此处的函数以如下方式包装给定的处理程序:
- 上下文被从请求中拉出 —
r.Context()
- 使用我们的新键和
w ResponseWriter
值“丰富”了 —context.WithValue(...,w)
- 请求的上下文被更新的上下文替换 —
r.WithContext(rctx)
- 使用此更新的请求运行包装的处理程序 —
handler.ServeHTTP(w,...)
在一些 http.Handler 中,您可以像这样提取值:
func someHandler(w http.ResponseWriter,r *http.Request) {
value,ok := r.Context().Value(ctxResponseWriter).(http.ResponseWriter)
if ok {
// we have the value!
}
}
这一定只是一个用法示例。像这样传递 ResponseWriter 是非常愚蠢的,因为它已经作为参数传递给任何 http.Handler ,正如您在上面看到的那样,并且从应用程序的更深层次依赖它是糟糕的设计。例如,更好的用途可能是传递请求范围的记录器对象。