HTTP中间件开发人员应该知道的事情

英文原文:https://github.com/mholt/caddy/wiki/Things-HTTP-Middleware-Developers-Should-Know


本文完善中(WIP)。

  • 使用httpserver.Path比较基本路径,以了解你的处理器是否应该处理请求(例如:httpserver.Path(r.URL.Path).Matches(myHandler.BasePath))
  • 不要直接使用来自请求的路径访问文件系统,因为这样做容易受到路径遍历攻击。应该这样:
    • 要打开文件,使用http.Dir(标准库)
    • 对于其他内容,请使用httpserver.SafePath去找一条经过特殊处理的路径
  • 如果中间件访问磁盘上的文件,则对HiddenFiles字段使用SiteConfig结构。
  • 如果需要包装或记录响应,请将自己的ResponseWriter类型使用httpserver.ResponseWriterWrapper类型包装,这样可以保证它实现一些关键的接口。
  • http.Request.URL(尤其是它的.Path值)可能会被其他“重写”中间件更改。你总是可以通过上下文访问原始传入URL:req.Context().Value(httpserver.OriginalURLCtxKey).(url.URL)
  • 指令(和子指令)遵循underscore_convention来命名。小写字母,下划线作为单词分隔符。可能有很少的例外(例如,header指令使用header字段名,比如Content-Type作为子指令),但通常尝试遵循这种约定。它将使用户对中间件的体验与Caddy的其余部分保持一致。避免驼峰或使用-分隔单词。
  • 指令的第一个参数(如果适用)通常是用于匹配请求的基本路径。
  • staticfiles.IndexPages一起使用httpserver.IndexFile(),用于确定文件是否是索引文件。

对于插件作者(TODO:当我们获得足够的内容时,移动到单独的文章):

  • 插件可能使用vendor目录作为依赖而且不导出vendor目录里的类型(也就是说,它们不与Caddy或任何其他插件共享vendor类型)。请参阅https://github.com/mattfarina/golang-broken-vendor,了解为什么这很糟糕。(注意/待办事项:在Go 1.9发布之前,插件应该只允许通过Caddy构建检查的供应商副总裁,比如test -racevet。因为Go 1.8-工具不会忽略供vendor/目录...)
  • 不要vendorgithub.com/mholt/caddy或者该代码库中的任何包,或任何你的插件“resisters”的包也插入到Caddy中。这样做将会导致你的插件使用vendor副本注册,而不是“main”包的编译源。