nosurf,这是Go语言的一个CSRF跨站请求伪造(Cross-Site Request Forgery)中间件。编写一个看起来简单并且小巧的包就足以让你爱上Go处理HTTP的方式。然而,这却取决于我们拥抱标准的HTTP设施或者是粉碎它,牺牲可组性和模块化。
http.Handler是接口
使用特定编程语言编写的web应用程序中的统一HTTP接口,如Python中的WSGI和Ruby中的Rack都是一种很好的想法,但是它们却不总是在一起,例如,Rack在2007年出现的时候,Rails就已经很健壮并且风靡了好一阵子。
与此同时,在Go语言中,唯一需要的接口自2009年就一直在发展中,尽管它从那时起经历了许多严重的改变,但是在2011年末,Go 1.0发布前的几个月,它已经变得非常稳定。
当然,我说的是mightyhttp.Handler。
type Handler interface { ServeHTTP(ResponseWriter, *Request) }
为了能够处理HTTP请求,你的类型仅仅需要实现这个方法就可以了。这个方法从给定的*Request读取请求信息,并且将响应信息写在给定的ResponseWriter中。看起来很简单,是吧?
补充它,但不能取代它
然而,在此基础之上的建立抽象时,有些东西弄错了。举个例子,Mango,被它的作者描述为“一个模块化的Go语言Web应用程序框架,灵感来自Rack和PEP333”。
这是一个Mango应用程序的样子:
func Hello(env mango.Env) (mango.Status, mango.Headers, mango.Body) { return 200, mango.Headers{}, mango.Body("Hello World!") }
看起来简单,简洁,并且非常类似于WSGI或者Rack,对不对?除了一件事情。在使用动态/鸭式类型时,你可以在任何一个body上用上迭代,这里的mango.Body只是一个简单的字符串。从本质上讲,这样就丢掉了做任何形式的流式响应的能力。即便是暴露一个ResponseWriter,任何写入它的东西都将与返回的值冲突,因为它们只在函数结束时返回,在已经调用了ResponseWriter之后。
这不好。你是否需要基于现有的net/http的另外一个接口,只是你的口味问题,但即使你这样做了,它也不应该拿掉其它的功能。一个接口,在其上的编写代码感觉更棒,但是它带走了重要的功能,显然就逊色了。
正确的方法
现在流行的一个“微型”Web框架web.go使用了一种简单,但更好的方法。它的处理程序使用一个指向web.Contextas的指针作为可选的第一个参数。
type Context struct { Request *http.Request Params map[string]string Server *Server http.ResponseWriter } // ... func hello(ctx *web.Context, val string) string { return "hello " + val }
web.Context不再采取标准的HTTP处理程序结构。相反,Request参数可作为结构成员和Context,实现ResponseWriter所需要的方法,故而就让它自身就嵌入了原来的ResponseWriter。你从函数返回字符串(如果有的话)只是简单的追加到了response上。
这是一个很好的设计选择,我认为它能迎合Go的理念。尽管你得到一个不错的更高级别的API,但你不必牺牲对请求处理的底层控制。
Go的HTTP库基础设施,尽管增长迅速,却仍然有一些空白需要填补。但是我们需要注意的最后一件事是碎片与恼人的不兼容性,这是由于糟糕的设计和实际上带走许多功能的抽象所导致。依我之见,拥抱和支持标准的Go HTTP设施就是,最直接地拥有功能化和模块化的第三方HTTP工具。
转自:http://www.oschina.net/translate/embrace-gos-http-tools
原文:http://justinas.org/embrace-gos-http-tools/
有疑问加站长微信联系(非本文作者)