[译] HTTP Request Contexts & Go

这篇文章是 Golang 开源库 Negroni 的 README.md 中推荐一篇的文章,讲的是 Golang 中如何处理请求的上下文信息。

原文链接 HTTP Request Contexts & Go

注:本文中 将 Handler 翻译为处理器,middleware 翻译成中间件,Request Context 翻译为请求上下文。

正文:

这篇文章其实也可以用 map[string]interface 作为标题。

如果我们想让HTTP请求时携带一些需要一系列处理程序或中间件处理的数据,一种典型的方式是使用 Request contexts. 这些数据可以是用户ID,CSRF token,或者一些数据表示用户是否已经登录或一些你不想在每个处理器都重复一遍的逻辑。如果你用过Django,request context 就是 request.META 字典。

比如:

func CSRFMiddleware(http.Handler) http.Handler {
   return func(w http.ResponseWriter, r *http.Request) {
       maskedToken, err := csrf.GenerateNewToken(r)
       if err != nil {
           http.Error(w, "No good!", http.StatusInternalServerError)
           return
       }
       // 我们如何把 maskedToken 从这里传出去 。。。
   }
}

func MyHandler(w http.ResponseWriter, r *http.Request) {  
   // 。。。传到这里,不依赖 session 的存储,
   // 而且不依赖绑定另一个处理器的处理器?
   // CSRF token 怎么办?或者 request header 里面 auth-key?
   // 我们肯定不想在每个处理器里面把这些逻辑都重写一遍!
}

在Go语言的 web库/框架 中,我们有三种方法解决这个问题:

  1. 创建一个全局 map, *http.Request

    作为 key, 同步互斥写入,中间件负责清理旧的请求 (gorilla/context ).

  2. 通过创建自定义的处理器类型(handler types), 为每个 request 指定一个 map (goji)。

  3. Structs, 自定义 structs, 为它创建以指针为接收器的中间件方法,或者将这些结构体对象作为参数传递给处理器 (gocraft/web)。

那么,这些方法有什么区别,各自又有什么优劣呢?

全局上下文 Map


gorilla/context 的实现方式最简单、最容易集成到已有的架构。Gorilla 其实用的是 map[interface{}]interface{} 结构,这意味着你需要(且应该)为你的 keys 创建类型。好处是你能用任何类型最为一个 key; 缺点是如果不想引发 run-time 问题,你得提前实现你的 keys.

为了避免相同的类型断言污染你的处理器,你还应该为这些 types 创建一些 setters 用来存储你的上下文 map。

import (
    "net/http"
    "github.com/gorilla/context"
)

type contextKey int

/ 定义一些竞争平等的 key
const csrfKey contextKey = 0
const userKey contextKey = 1

var ErrCSRFTokenNotPresent = errors.New("CSRF token not present in the request context.")

// 对每一个存储在 context map 里面的 key:value 组合,
// 我们都需要一个像这样的辅助方法,
// 不然我们就会在每个需要这个值的中间件中重复这些代码。
func GetCSRFToken(r *http.Request) (string, error) {
    val, ok := context.GetOk(r, csrfKey)
    if !ok {
        return "", ErrCSRFTokenNotPresent
    }

    token, ok := val.(string)
    if !ok {
        return "", ErrCSRFTokenNotPresent
    }

    return token, nil
}

// 一个简单的示例
func CSRFMiddleware(h http.Handler) http.Handler {
    return func(w http.ResponseWriter, r *http.Request) {
        token, err := GetCSRFToken(r)
        if err != nil {
            http.Error(w, "No good!", http.StatusInternalServerError)
            return
        }

        // 这个 map 是全局的,所以我们只调用 Set 方法
        context.Set(r, csrfKey, token)

        h.ServeHTTP(w, r)
    }
}

func ShowSignupForm(w http.ResponseWriter, r *http.Request) {

    // 我们用自己的辅助方法,
    // 所以我们不需要维护每个触发或处理 POST 请求的处理器中数据类型
    csrfToken, err := GetCSRFToken(r)
    if err != nil {
        http.Error(w, "No good!", http.StatusInternalServerError)
        return
    }

    // 我们在每一个用我们的中间件包装的处理器中都能访问到这个 token. 
    // 而不需要在每次请求中从 session 里多次读取(这种方法很慢)。
    fmt.Fprintf(w, "Our token is %v", csrfToken)
}


func main() {
    r := http.NewServeMux()
    r.Handle("/signup", CSRFMiddleware(http.HandlerFunc(ShowSignupForm)))
    // 这里必须调用 context.ClearHandler,
    // 否则将会把旧的请求留在 map 中。
    http.ListenAndServe("localhost:8000", context.ClearHandler(r))
}

完整示例

优点?灵活,松耦合,第三方包容易使用。你可以把它用在任何 net/http 应用中,因为你要做的只是访问 http.Request——剩下的依赖就只有 global map 了。

缺点?global map 和其互斥器(mutexes) 有可能 导致高链接负载,所以你需要在每个请求(即每个处理器) 里最后调用 context.Clear(). 如果忘了清理(或者对你的上层服务器处理器包了一层), 你会让自己陷入内存泄露的危险,因为老的请求依然存在 map 中。如果你的中间件用了 gorilla/context, 那么得确保你引入了 contex 而且在处理器/路由中调用了 context.ClearHandler。

每个请求一个 map[string]interface


作为另一种方式,Goji 提供了一个嵌入到 http.Handler 的请求上下文。 因为它绑定在了 Goji 的路由具体实现代码中, 所以它不需要是一个全局 map 而且也避免了使用互斥锁。Goji 提供了一个 web.HandlerFunc 类型,它通过 func(c web.C, w http.ResponseWriter, r *http.Request) 扩展了默认的 http.HandlerFunc.

var ErrTypeNotPresent = errors.New("Expected type not present in the request context.")

// 相对简单点:我们对每一个 *类型*, 我们只需要这一个方法
func GetContextString(c web.C, key string) (string, error) {
   val, ok := c.Env[key].(string)
   if !ok {
       return "", ErrTypeNotPresent
   }

   return val, nil
}

// 一个简单示例
func CSRFMiddleware(c *web.C, h http.Handler) http.Handler {
   fn := func(w http.ResponseWriter, r *http.Request) {
       maskedToken, err := GenerateToken(r)
       if err != nil {
           http.Error(w, "No good!", http.StatusInternalServerError)
           return
       }

       // Goji 只在你需要的时候分配一个 map
       if c.Env == nil {
           c.Env = make(map[string]interface{})
       }

       // 不是全局变量 —— 只是一个 context map 的引用,
       // 它显式传递给我们我的处理器。
       c.Env["csrf_token"] = maskedToken

       h.ServeHTTP(w, r)
   }

   return http.HandlerFunc(fn)
}

// Goji 的 web.HandlerFunc 类型是 net/http.HandlerFunc 的扩展,
// 它会被参数传递给 request context(又称 web.C.Env)
func ShowSignupForm(c web.C, w http.ResponseWriter, r *http.Request) {

   csrfToken, err := GetContextString(c, "csrf_token")
   if err != nil {
       http.Error(w, "No good!", http.StatusInternalServerError)
       return
   }

   fmt.Fprintf(w, "Our token is %v", csrfToken)
}

完整示例

最大最直接的好处就是性能提升,因为 Goji 只在你需要的时候它才会分配一个 map: 不存在全局 map锁 的问题。注意,对于很多应用,数据库和模板渲染时将会是性能的瓶颈所在,所以“真正”的影响可能很小,但是这正是二者之间一个合理的联系。

最有用的是,你依然可以写不需要应用信息的模块化中间件,而且如果你想用 request context,马上就可以用,但是除了这个,它就是个 http.Handler. 缺点是,你依然需要维护从 context 拿到的数据的类型,尽管像 gorilla/context, 我们可以用 helper方法 简化这些操作,但 map[string]interface{} 还会限制我们只能用 string key: 对大多数人(包括我)来说很简单,但可能对有些人来说缺少灵活性。

Context Structs


第三种方式是为每一个请求初始化一个 struct, 然后把我们的 中间件/处理器 定义为它的方法。最大的好处是类型安全:我们明确地定义了请求的上下文,所以我们知道它的类型(除非我们定义了一个 interface{} 的字段).

当然,在你可以保证类型安全的同时你也失去了灵活性。你不能创建一个可以使用 func(http.Handler) http.Handler 模式的“模块化”中间件,因为这个中间件不知道你的请求上线文 struct 是什么。它可以提供他自己的 struct 并嵌入到你的 struct 中,但这依然不能重用。然而,这是一种不错的方法:除了 interface{} 以外,你不需要维护类型。

import (
   "fmt"
   "log"
   "net/http"

   "github.com/gocraft/web"
)

type Context struct {
   CSRFToken string
   User     string
}

// 我们的中间件*和*处理器必须都定义为 context struct 的方法,或者接受 context struct 作为第一个参数。
// 这就会把 处理器/中间件 和具体的应用 架构/设计 绑在一起。
func (c *Context) CSRFMiddleware(w web.ResponseWriter, r *web.Request, next web.NextMiddlewareFunc) {
   token, err := GenerateToken(r)
   if err != nil {
       http.Error(w, "No good!", http.StatusInternalServerError)
       return
   }

   c.CSRFToken = token
   next(w, r)
}

func (c *Context) ShowSignupForm(w web.ResponseWriter, r *web.Request) {
   // 不需要维护它:我们知道它的类型。
   // 我们能直接用这个值。
   fmt.Fprintf(w, "Our token is %v", c.CSRFToken)
}

func main() {
   router := web.New(Context{}).Middleware((*Context).CSRFMiddleware)
   router.Get("/signup", (*Context).ShowSignupForm)

   err := http.ListenAndServe(":8000", router)
   if err != nil {
       log.Fatal(err)
   }
}

完整示例

优点很显然:没有类型维护!我们的 struct 有明确的类型而且对每个请求进行初始化,然后传递给我们的 中间件/处理器。但,缺点是社区的中间件再也不能“即插即用”了,因为它们的设计肯定不会考虑我们的上下文。

我们可以将它们的类型匿名嵌入到我们的 struct 中,但是这会让我们的代码变得很乱,而且如果它们命名和我们的一样,还是行不通。现实的解决方案是 fork 一份代码,然后修改以让我们的 struct 能够使用,代价就是时间和精力。gocraft/web 也是用他们自己的类型包装了 ResponseWriter interface/Request struct,这和框架本身关系更密切。

其他的解决方案?


一个解决方案是,Go 的 http.Request struct 提供一个 Context 属性,但是事实上,以合乎情理的方式实现一个可以适合一般场景的请求上下文并不是那么容易。

这个属性应该是一个 map[string]interface{} (或者以interface{} 作为 key). 这意味着我们要么需要为使用者初始化这个 map ——这对于那些不需要请求上下文的使用者来说没什么用。或者需要包使用者在使用之前检查,这会让一些新手在一开始感到困惑,为什么他们的应用对于有些请求报错而其他的却没有。

我觉得着对于 net/http 本身来说都不是什么大的障碍,但是 Go 的设计理念是清晰、容易理解 —— 这么做代价是有时有点啰嗦 —— 这有可能有些违背设计理念。我也认为有些 第三方包/框架 给我们选择没什么不好的:选择最适合你的方式。

总结


所以你会为你的项目选择什么方式呢?这取决于你的使用场景。想写一个便于使用者调用请求上下文,而且相对独立的包?gorilla/context 可能是个不错的选择(提醒:别忘了调用 ClearHandler!)。从头写或者打算扩展一个 net/http 应用?Goji 可以很容易上手。从零做起?gocraft/web 整套解决方案也许会比较适合你。

我个人比较喜欢 Goji 的解决方案:我不介意写一些辅助方法去维护我常用的请求上下文类型(CSRF token,用户名,等), 而且我尽量避免全局 map. 对我来说,可以很容易写一些可以被别人集成到他们项目中的中间件。但这只是我自己的使用场景,所以你得先针对自己的情况做些调查。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,117评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,963评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,897评论 0 240
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,805评论 0 203
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,208评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,535评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,797评论 2 311
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,493评论 0 197
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,215评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,477评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,988评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,325评论 2 252
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,971评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,807评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,544评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,455评论 2 266

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,099评论 18 139
  • [TOC]一直想做源码阅读这件事,总感觉难度太高时间太少,可望不可见。最近正好时间充裕,决定试试做一下,并记录一下...
    何柯君阅读 7,030评论 3 98
  • 从三月份找实习到现在,面了一些公司,挂了不少,但最终还是拿到小米、百度、阿里、京东、新浪、CVTE、乐视家的研发岗...
    时芥蓝阅读 42,014评论 11 349
  • 22年12月更新:个人网站关停,如果仍旧对旧教程有兴趣参考 Github 的markdown内容[https://...
    tangyefei阅读 35,127评论 22 257
  • 概述 Struts就是基于mvc模式的框架!(struts其实也是servlet封装,提高开发效率!) Strut...
    奋斗的老王阅读 2,839评论 0 51