在web开发过程中，中间件一般是指应用程序中封装原始信息，添加额外功能的组件。不知道为什么，中间件通常是一种不太受欢迎的概念。但我认为它棒极了。
其一，一个好的中间件拥有单一的功能，可插拔并且是自我约束的。这就意味着你可以在接口的层次上把它放到应用中，并能很好的工作。中间件并不影响你的代码风格，它也不是一个框架，仅仅是你处理请求流程中额外一层罢了。根本不需要重写代码：如果你想用一个中间件，就把它加上应用中；如果你改变主意了，去掉就好了。就这么简单。
来看看Go，HTTP中间件非常流行，标准库中也是这样。或许咋看上去并不明显，net/http包中的函数，如StripPrefix 和TimeoutHandler 正是我们上面定义的中间件：封装处理过程并在处理输入或输出时增加额外的动作。
我最近的Go包 nosurf 也是一个中间件。我从一开始就有意的这样设计。大多数情况下，你根本不必在应用层关心CSRF检查。nosurf，和其他中间件一样，非常独立，可以和实现标准库net/http接口的工具配合使用。
你也可以使用中间件做这些：
* 通过隐藏长度缓解BREACH攻击
* 频率限制
* 屏蔽恶意自动程序
* 提供调试信息
* 添加HSTS, X-Frame-Options头
* 从异常中优雅恢复
* 以及其他等等。
写一个简单的中间件
第一个例子中，我写了一个中间件，只允许用户从特定的域（在HTTP的Host头中有域信息）来访问服务器。这样的中间件可以保护应用程序不受“主机欺骗攻击”
定义类型
为了方便，让我们为这个中间件定义一种类型，叫做SingleHost。
type SingleHost struct {
handler http.Handler
allowedHost string
}
只包含两个字段：
* 封装的Handler。如果是有效的Host访问，我们就调用这个Handler。
* 允许的主机值。
由于我们把字段名小写了，使得该字段只对我们自己的包可见。我们还应该写一个初始化函数。
func NewSingleHost(handler http.Handler, allowedHost string) *SingleHost {
return &SingleHost{handler: handler, allowedHost: allowedHost}
}
处理请求
现在才是实际的逻辑。为了实现http.Handler，我们的类型秩序实现一个方法：
type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}
这就是我们实现的方法：
func (s *SingleHost) ServeHTTP(w http.ResponseWriter, r *http.Request) {
host := r.Host
if host == s.allowedHost {
s.handler.ServeHTTP(w, r)
} else {
w.WriteHeader(403)
}
}
ServeHTTP 函数仅仅检查请求中的Host头：
- 如果Host头匹配初始化函数设置的allowedHost ，就调用封装handler的ServeHTTP方法。
- 如果Host头不匹配，就返回403状态码（禁止访问）。
在后一种情况中，封装handler的ServeHTTP方法根本就不会被调用。因此封装的handler根本不会有任何输出，实际上它根本就不知道有这样一个请求到来。
现在我们已经完成了自己的中间件，来把它放到应用中。这次我们不把Handler直接放到net/http服务中，而是先把Handler封装到中间件中。
singleHosted = NewSingleHost(myHandler, "example.com")
http.ListenAndServe(":8080", singleHosted)
另外一种方法
我们刚才写的中间件实在是太简单了，只有仅仅15行代码。为了写这样的中间件，引入了一个不太通用的方法。由于Go支持函数第一型和闭包，并且拥有简洁的http.HandlerFunc包装器，我们可以将其实现为一个简单的函数，而不是写一个单独的类型。下面是基于函数的中间件版本。
func SingleHost(handler http.Handler, allowedHost string) http.Handler {
ourFunc := func(w http.ResponseWriter, r *http.Request) {
host := r.Host
if host == allowedHost {
handler.ServeHTTP(w, r)
} else {
w.WriteHeader(403)
}
}
return http.HandlerFunc(ourFunc)
}
这里我们声明了一个叫做SingleHost的简单函数，接受一个Handler和允许的主机名。在函数内部，我们创建了一个类似之前版本ServeHTTP的函数。这个内部函数其实是一个闭包，所以它可以从SingleHost外部访问。最终，我们通过HandlerFunc把这个函数用作http.Handler。
使用Handler还是定义一个http.Handler类型完全取决于你。对简单的情况而已，一个函数就足够了。但是随着中间件功能的复杂，你应该考虑定义自己的数据结构，把逻辑独立到多个方法中。
实际上，标准库这两种方法都用了。StripPrefix 是一个返回HandlerFunc的函数。虽然TimeoutHandler也是一个函数，但它返回了处理请求的自定义的类型。
更复杂的情况
我们的SingleHost中间件非常简单：先检查请求的一个属性，然后要么什么也不管，把请求直接传给封装的Handler；要么自己返回一个响应，根本不让封装的Handler处理这次请求。然而，有些情况是这样的，不但基于请求触发一些动作，还要在封装的Handler处理后做一些扫尾工作，比如修改响应内容等。
添加数据比较容易
如果我们想在封装的handler输出的内容后添加一些数据，我们只需要在handler结束后继续调用Write()即可：
type AppendMiddleware struct {
handler http.Handler
}
func (a *AppendMiddleware) ServeHTTP(w http.ResponseWriter, r *http.Request) {
a.handler.ServeHTTP(w, r)
w.Write([]byte("Middleware says hello."))
}
响应内容现在就应该包含封装的handler的内容，再加上Middleware says hello.
问题是
做其他的响应内容操作比较麻烦。比如，如果我们想在响应内容前写入一些数据。如果我们在封装的handler前调用Write()，那么封装的handler就好失去对HTTP状态码和HTTP头的控制。因为第一次调用Write()会直接将头输出。
想要修改原有输出（比如，替换其中的某些字符串），改变特定的HTTP头，设置不同的状态码也都因为同样的原因而不可行：当封装的handler返回时，上述数据早已被发送给客户端了。
为了处理这样的需求，我们需要一种特殊的可以用做buffer的ResponseWriter,它能够收集、暂存输出以用于修改等操作，最后再发送给客户端。我们可以将这个带buffer的ResponseWriter传给封装的handler，而不是真实的RW，这样就避免直接发送数据给客户端。
幸运的是，在Go标准库中确实存在这样一个工具。net/http/httptest中的ResponseRecorder就是这样的：它保存状态码，一个保存响应头的字典，将输出累计在buffer中。尽管是用于测试（这个包名暗示了这一点），它还是很好的满足了我们的需求。
让我们看一个使用ResponseRecorder的例子，这里修改了响应内容的所有东西，是为了更完整的演示。
type ModifierMiddleware struct {
handler http.Handler
}
func (m *ModifierMiddleware) ServeHTTP(w http.ResponseWriter, r *http.Request) {
rec := httptest.NewRecorder()
// passing a ResponseRecorder instead of the original RW
m.handler.ServeHTTP(rec, r)
// after this finishes, we have the response recorded
// and can modify it before copying it to the original RW
// we copy the original headers first
for k, v := range rec.Header() {
w.Header()[k] = v
}
// and set an additional one
w.Header().Set("X-We-Modified-This", "Yup")
// only then the status code, as this call writes out the headers
w.WriteHeader(418)
// the body hasn't been written (to the real RW) yet,
// so we can prepend some data.
w.Write([]byte("Middleware says hello again. "))
// then write out the original body
w.Write(rec.Body.Bytes())
}
下面是我们包装的handler的输出。如果不用我们的中间件封装，原来的handler仅仅会输出Success！。
HTTP/1.1 418 I'm a teapot
X-We-Modified-This: Yup
Content-Type: text/plain; charset=utf-8
Content-Length: 37
Date: Tue, 03 Sep 2013 18:41:39 GMT
Middleware says hello again. Success!
这种方式提供了非常大的便利。被封装的handler现在完全在我们的控制之下：即使在其返回之后，我们也可以以任意方式操作输出。
和其他handlers共享数据
在不同的情况下，中间件可以需要给其他的中间件或者应用程序暴露特定的信息。比如，nosurf需要给用户提供一种获取CSRF 密钥的方式以及错误原因（如果有错误的话）。
对这种需求，一个合适的模型就是使用一个隐藏的map，将http.Request指针指向需要的数据，然后暴露一个包级别（handler级别）的函数来访问这些数据。
我在nosurf中也使用了这种模型。这里，我创建了一个全局的上下文map。注意到，由于默认情况下Go的map并不是[并发访问安全](http://blog.golang.org/go-maps-in-action#TOC_6.）的，需要一个mutex。
type csrfContext struct {
token string
reason error
}
var (
contextMap = make(map[*http.Request]*csrfContext)
cmMutex = new(sync.RWMutex)
)
使用handler设置数据，然后通过暴露的函数Token()来获取数据。
func Token(req *http.Request) string {
cmMutex.RLock()
defer cmMutex.RUnlock()
ctx, ok := contextMap[req]
if !ok {
return ""
}
return ctx.token
}
你可以在nosurf的代码库context.go中找到完整的实现。
虽然我选择在nosurf中自己实现这种需求，但实际上存在一个方便的 gorilla/context包，它实现了一个通用的保存请求信息的map。在大多数情况下，这个包足以满足你的需求，避免你在自己实现一个共享存储时踩坑。它甚至还有一个自己的中间件能在请求处理结束之后清除请求信息。
总结
这篇文章的目的是吸引Go用户对中间件概念的注意以及展示使用Go写中间件的一些基本组件。尽管Go是一个相对年轻的开发语言，Go拥有非常漂亮的标准HTTP接口。这也是用Go写中间件是个非常简单甚至快乐的过程的原因之一。
然而，目前Go仍然缺乏高质量的HTTP工具。我之前提到的Go中间件想法，大多都还没实现。现在你已经知道如何用Go写中间件了，为什么不自己做一个呢？
PS，你可以在一个GitHub gist中找到这篇文章中所有的中间件例子。
原文链接： Writing HTTP Middleware in Go
转载自： 伯乐在线 - Codefor
有疑问加站长微信联系（非本文作者）
