koa源码阅读[3]-koa-send与它的衍生(static)

koa源码阅读的第四篇,涉及到向接口请求方提供文件数据。

koa源码阅读[2]-koa-router

第三篇,有关koa生态中比较重要的一个中间件:koa-router

第一篇:koa源码阅读-0
第二篇:koa源码阅读-1-koa与koa-compose

第一篇:koa源码阅读-0
第二篇:koa源码阅读-1-koa与koa-compose
第三篇:koa源码阅读-2-koa-router

koa-router是什么

首先,因为koa是一个管理中间件的平台,而注册一个中间件使用use来执行。
无论是什么请求,都会将所有的中间件执行一遍(如果没有中途结束的话)
所以,这就会让开发者很困扰,如果我们要做路由该怎么写逻辑?

app.use(ctx => {
  switch (ctx.url) {
    case '/':
    case '/index':
      ctx.body = 'index'
      break
    case 'list':
      ctx.body = 'list'
      break
    default:
      ctx.body = 'not found'
  }
})

 

诚然,这样是一个简单的方法,但是必然不适用于大型项目,数十个接口通过一个switch来控制未免太繁琐了。
更何况请求可能只支持get或者post,以及这种方式并不能很好的支持URL中包含参数的请求/info/:uid
express中是不会有这样的问题的,自身已经提供了getpost等之类的与METHOD同名的函数用来注册回调:
express

const express = require('express')
const app = express()

app.get('/', function (req, res) {
  res.send('hi there.')
})

 

但是koa做了很多的精简,将很多逻辑都拆分出来作为独立的中间件来存在。
所以导致很多express项目迁移为koa时,需要额外的安装一些中间件,koa-router应该说是最常用的一个。
所以在koa中则需要额外的安装koa-router来实现类似的路由功能:
koa

const Koa = require('koa')
const Router = require('koa-router')

const app = new Koa()
const router = new Router()

router.get('/', async ctx => {
  ctx.body = 'hi there.'
})

app.use(router.routes())
  .use(router.allowedMethods())

 

看起来代码确实多了一些,毕竟将很多逻辑都从框架内部转移到了中间件中来处理。
也算是为了保持一个简练的koa框架所取舍的一些东西吧。
koa-router的逻辑确实要比koa的复杂一些,可以将koa想象为一个市场,而koa-router则是其中一个摊位
koa仅需要保证市场的稳定运行,而真正和顾客打交道的确是在里边摆摊的koa-router

处理静态文件是一个繁琐的事情,因为静态文件都是来自于服务器上,肯定不能放开所有权限让接口来读取。
各种路径的校验,权限的匹配,都是需要考虑到的地方。
koa-sendkoa-static就是帮助我们处理这些繁琐事情的中间件。
koa-sendkoa-static的基础,可以在NPM的界面上看到,staticdependencies中包含了koa-send

koa-router的大致结构

koa-router的结构并不是很复杂,也就分了两个文件:

.
├── layer.js
└── router.ja

 

layer主要是针对一些信息的封装,主要路基由router提供:

tag desc
layer 信息存储:路径、METHOD、路径对应的正则匹配、路径中的参数、路径对应的中间件
router 主要逻辑:对外暴露注册路由的函数、提供处理路由的中间件,检查请求的URL并调用对应的layer中的路由处理

金沙官网线上 1

koa-router的运行流程

可以拿上边所抛出的基本例子来说明koa-router是怎样的一个执行流程:

const router = new Router() // 实例化一个Router对象

// 注册一个路由的监听
router.get('/', async ctx => {
  ctx.body = 'hi there.'
})

app
  .use(router.routes()) // 将该Router对象的中间件注册到Koa实例上,后续请求的主要处理逻辑
  .use(router.allowedMethods()) // 添加针对OPTIONS的响应处理,一些预检请求会先触发 OPTIONS 然后才是真正的请求

 

koa-send主要是用于更方便的处理静态文件,与koa-router之类的中间件不同的是,它并不是直接作为一个函数注入到app.use中的。
而是在某些中间件中进行调用,传入当前请求的Context及文件对应的位置,然后实现功能。

创建实例时的一些事情

首先,在koa-router实例化的时候,是可以传递一个配置项参数作为初始化的配置信息的。
然而这个配置项在readme中只是简单的被描述为:

Param Type Description
[opts] Object  
[opts.prefix] String prefix router paths(路由的前缀)

告诉我们可以添加一个Router注册时的前缀,也就是说如果按照模块化分,可以不必在每个路径匹配的前端都添加巨长的前缀:

const Router = require('koa-router')
const router = new Router({
  prefix: '/my/awesome/prefix'
})

router.get('/index', ctx => { ctx.body = 'pong!' })

// curl /my/awesome/prefix/index => pong!

 

P.S. 不过要记住,如果prefix/结尾,则路由的注册就可以省去前缀的/了,不然会出现/重复的情况

实例化Router时的代码:

function Router(opts) {
  if (!(this instanceof Router)) {
    return new Router(opts)
  }

  this.opts = opts || {}
  this.methods = this.opts.methods || [
    'HEAD',
    'OPTIONS',
    'GET',
    'PUT',
    'PATCH',
    'POST',
    'DELETE'
  ]

  this.params = {}
  this.stack = []
}

 

可见的只有一个methods的赋值,但是在查看了其他源码后,发现除了prefix还有一些参数是实例化时传递进来的,但是不太清楚为什么文档中没有提到:

Param Type Default Description
sensitive Boolean false 是否严格匹配大小写
strict Boolean false 如果设置为false则匹配路径后边的/是可选的
methods Array[String] ['HEAD','OPTIONS','GET','PUT','PATCH','POST','DELETE'] 设置路由可以支持的METHOD
routerPath String null  

koa-send的GitHub地址

sensitive

如果设置了sensitive,则会以更严格的匹配规则来监听路由,不会忽略URL中的大小写,完全按照注册时的来匹配:

const Router = require('koa-router')
const router = new Router({
  sensitive: true
})

router.get('/index', ctx => { ctx.body = 'pong!' })

// curl /index => pong!
// curl /Index => 404

 

原生的文件读取、传输方式

Node中,如果使用原生的fs模块进行文件数据传输,大致是这样的操作:

const fs      = require('fs')
const Koa     = require('koa')
const Router  = require('koa-router')

const app     = new Koa()
const router  = new Router()
const file    = './test.log'
const port    = 12306

router.get('/log', ctx => {
  const data = fs.readFileSync(file).toString()
  ctx.body = data
})

app.use(router.routes())
app.listen(port, () => console.log(`Server run as http://127.0.0.1:${port}`))

 

或者用createReadStream代替readFileSync也是可行的,区别会在下边提到

这个简单的示例仅针对一个文件进行操作,而如果我们要读取的文件是有很多个,甚至于可能是通过接口参数传递过来的。
所以很难保证这个文件一定是真实存在的,而且我们可能还需要添加一些权限设置,防止一些敏感文件被接口返回。

router.get('/file', ctx => {
  const { fileName } = ctx.query
  const path = path.resolve('./XXX', fileName)
  // 过滤隐藏文件
  if (path.startsWith('.')) {
    ctx.status = 404
    return
  }

  // 判断文件是否存在
  if (!fs.existsSync(path)) {
    ctx.status = 404
    return
  }

  // balabala

  const rs = fs.createReadStream(path)
  ctx.body = rs // koa做了针对stream类型的处理,详情可以看之前的koa篇
})

 

添加了各种逻辑判断以后,读取静态文件就变得安全不少,可是这也只是在一个router中做的处理。
如果有多个接口都会进行静态文件的读取,势必会存在大量的重复逻辑,所以将其提炼为一个公共函数将是一个很好的选择。

strict

strictsensitive功能类似,也是用来设置让路径的匹配变得更加严格,在默认情况下,路径结尾处的/是可选的,如果开启该参数以后,如果在注册路由时尾部没有添加/,则匹配的路由也一定不能够添加/结尾:

const Router = require('koa-router')
const router = new Router({
  strict: true
})

router.get('/index', ctx => { ctx.body = 'pong!' })

// curl /index  => pong!
// curl /Index  => pong!
// curl /index/ => 404

 

koa-send的方式

这就是koa-send做的事情了,提供了一个封装非常完善的处理静态文件的中间件。
这里是两个最基础的使用例子:

const path = require('path')
const send = require('koa-send')

// 针对某个路径下的文件获取
router.get('/file', async ctx => {
  await send(ctx, ctx.query.path, {
    root: path.resolve(__dirname, './public')
  })
})

// 针对某个文件的获取
router.get('/index', async ctx => {
  await send(ctx, './public/index.log')
})

 

假设我们的目录结构是这样的,simple-send.js为执行文件:

.
├── public
│   ├── a.log
│   ├── b.log
│   └── index.log
└── simple-send.js

 

使用/file?path=XXX就可以很轻易的访问到public下的文件。
以及访问/index就可以拿到/public/index.log文件的内容。

methods

methods配置项存在的意义在于,如果我们有一个接口需要同时支持GETPOSTrouter.getrouter.post这样的写法必然是丑陋的。
所以我们可能会想到使用router.all来简化操作:

const Router = require('koa-router')
const router = new Router()

router.all('/ping', ctx => { ctx.body = 'pong!' })

// curl -X GET  /index  => pong!
// curl -X POST /index  => pong!

 

这简直是太完美了,可以很轻松的实现我们的需求,但是如果再多实验一些其他的methods以后,尴尬的事情就发生了:

> curl -X DELETE /index  => pong!
> curl -X PUT    /index  => pong!

 

这显然不是符合我们预期的结果,所以,在这种情况下,基于目前koa-router需要进行如下修改来实现我们想要的功能:

const Koa = require('koa')
const Router = require('router')

const app = new Koa()
// 修改处1
const methods = ['GET', 'POST']
const router = new Router({
  methods
})

// 修改处2
router.all('/', async (ctx, next) => {
  // 理想情况下,这些判断应该交由中间件来完成
  if (!~methods.indexOf(ctx.method)) {
    return await next()
  }

  ctx.body = 'pong!'
})

 

这样的两处修改,就可以实现我们所期望的功能:

> curl -X GET    /index  => pong!
> curl -X POST   /index  => pong!
> curl -X DELETE /index  => Not Implemented
> curl -X PUT    /index  => Not Implemented

 

我个人觉得这是allowedMethods实现的一个逻辑问题,不过也许是我没有get到作者的点,allowedMethods中比较关键的一些源码:

Router.prototype.allowedMethods = function (options) {
  options = options || {}
  let implemented = this.methods

  return function allowedMethods(ctx, next) {
    return next().then(function() {
      let allowed = {}

      // 如果进行了ctx.body赋值,必然不会执行后续的逻辑
      // 所以就需要我们自己在中间件中进行判断
      if (!ctx.status || ctx.status === 404) {
        if (!~implemented.indexOf(ctx.method)) {
          if (options.throw) {
            let notImplementedThrowable
            if (typeof options.notImplemented === 'function') {
              notImplementedThrowable = options.notImplemented() // set whatever the user returns from their function
            } else {
              notImplementedThrowable = new HttpError.NotImplemented()
            }
            throw notImplementedThrowable
          } else {
            ctx.status = 501
            ctx.set('Allow', allowedArr.join(', '))
          }
        } else if (allowedArr.length) {
          // ...
        }
      }
    })
  }
}

 

首先,allowedMethods是作为一个后置的中间件存在的,因为在返回的函数中先调用了next,其次才是针对METHOD的判断,而这样带来的一个后果就是,如果我们在路由的回调中进行类似ctx.body = XXX的操作,实际上会修改本次请求的status值的,使之并不会成为404,而无法正确的触发METHOD检查的逻辑。
想要正确的触发METHOD逻辑,就需要自己在路由监听中手动判断ctx.method是否为我们想要的,然后在跳过当前中间件的执行。
而这一判断的步骤实际上与allowedMethods中间件中的!~implemented.indexOf(ctx.method)逻辑完全是重复的,不太清楚koa-router为什么会这么处理。

当然,allowedMethods是不能够作为一个前置中间件来存在的,因为一个Koa中可能会挂在多个RouterRouter之间的配置可能不尽相同,不能保证所有的Router都和当前Router可处理的METHOD是一样的。
所以,个人感觉methods参数的存在意义并不是很大。。

koa-send提供的功能

koa-send提供了很多便民的选项,除去常用的root以外,还有大概小十个的选项可供使用:

options type default desc
maxage Number 0 设置浏览器可以缓存的毫秒数
对应的HeaderCache-Control: max-age=XXX
immutable Boolean false 通知浏览器该URL对应的资源不可变,可以无限期的缓存
对应的HeaderCache-Control: max-age=XXX, immutable
hidden Boolean false 是否支持隐藏文件的读取
.开头的文件被称为隐藏文件
root String - 设置静态文件路径的根目录,任何该目录之外的文件都是禁止访问的。
index String - 设置一个默认的文件名,在访问目录的时候生效,会自动拼接到路径后边 (此处有一个小彩蛋)
gzip Boolean true 如果访问接口的客户端支持gzip,并且存在.gz后缀的同名文件的情况下会传递.gz文件
brotli Boolean true 逻辑同上,如果支持brotli且存在.br后缀的同名文件
format Boolean true 开启以后不会强要求路径结尾的//path/path/表示的是一个路径 (仅在path是一个目录的情况下生效)
extensions Array false 如果传递了一个数组,会尝试将数组中的所有item作为文件的后缀进行匹配,匹配到哪个就读取哪个文件
setHeaders Function - 用来手动指定一些Headers,意义不大

routerPath

这个参数的存在。。感觉会导致一些很诡异的情况。
这就要说到在注册完中间件以后的router.routes()的操作了:

Router.prototype.routes = Router.prototype.middleware = function () {
  let router = this
  let dispatch = function dispatch(ctx, next) {
    let path = router.opts.routerPath || ctx.routerPath || ctx.path
    let matched = router.match(path, ctx.method)
    // 如果匹配到则执行对应的中间件
    // 执行后续操作
  }
  return dispatch
}

 

因为我们实际上向koa注册的是这样的一个中间件,在每次请求发送过来时,都会执行dispatch,而在dispatch中判断是否命中某个router时,则会用到这个配置项,这样的一个表达式:router.opts.routerPath || ctx.routerPath || ctx.pathrouter代表当前Router实例,也就是说,如果我们在实例化一个Router的时候,如果填写了routerPath,这会导致无论任何请求,都会优先使用routerPath来作为路由检查:

const router = new Router({
  routerPath: '/index'
})

router.all('/index', async (ctx, next) => {
  ctx.body = 'pong!'
})
app.use(router.routes())

app.listen(8888, _ => console.log('server run as http://127.0.0.1:8888'))

 

如果有这样的代码,无论请求什么URL,都会认为是/index来进行匹配:

> curl http://127.0.0.1:8888
pong!
> curl http://127.0.0.1:8888/index
pong!
> curl http://127.0.0.1:8888/whatever/path
pong!

 

参数们的具体表现

有些参数的搭配可以实现一些神奇的效果,有一些参数会影响到Header,也有一些参数是用来优化性能的,类似gzipbrotli的选项。

koa-send的主要逻辑可以分为这几块:

  1. path路径有效性的检查
  2. gzip等压缩逻辑的应用
  3. 文件后缀、默认入口文件的匹配
  4. 读取文件数据

在函数的开头部分有这样的逻辑:

const resolvePath = require('resolve-path')
const {
  parse
} = require('path')

async function send (ctx, path. opts = {}) {
  const trailingSlash = path[path.length - 1] === '/'
  const index = opts.index

  // 此处省略各种参数的初始值设置

  path = path.substr(parse(path).root.length)

  // ...

  // normalize path
  path = decode(path) // 内部调用的是`decodeURIComponent`
  // 也就是说传入一个转义的路径也是可以正常使用的

  if (index && trailingSlash) path += index

  path = resolvePath(root, path)

  // hidden file support, ignore
  if (!hidden && isHidden(root, path)) return
}

function isHidden (root, path) {
  path = path.substr(root.length).split(sep)
  for (let i = 0; i < path.length; i++) {
    if (path[i][0] === '.') return true
  }
  return false
}

 

巧用routerPath实现转发功能

同样的,这个短路运算符一共有三个表达式,第二个的ctx则是当前请求的上下文,也就是说,如果我们有一个早于routes执行的中间件,也可以进行赋值来修改路由判断所使用的URL

const router = new Router()

router.all('/index', async (ctx, next) => {
  ctx.body = 'pong!'
})

app.use((ctx, next) => {
  ctx.routerPath = '/index' // 手动改变routerPath
  next()
})
app.use(router.routes())

app.listen(8888, _ => console.log('server run as http://127.0.0.1:8888'))

 

这样的代码也能够实现相同的效果。
实例化中传入的routerPath让人捉摸不透,但是在中间件中改变routerPath的这个还是可以找到合适的场景,这个可以简单的理解为转发的一种实现,转发的过程是对客户端不可见的,在客户端看来依然访问的是最初的URL,但是在中间件中改变ctx.routerPath可以很轻易的使路由匹配到我们想转发的地方去

// 老版本的登录逻辑处理
router.post('/login', ctx => {
  ctx.body = 'old login logic!'
})

// 新版本的登录处理逻辑
router.post('/login-v2', ctx => {
  ctx.body = 'new login logic!'
})

app.use((ctx, next) => {
  if (ctx.path === '/login') { // 匹配到旧版请求,转发到新版
    ctx.routerPath = '/login-v2' // 手动改变routerPath
  }
  next()
})
app.use(router.routes())

 

这样就实现了一个简易的转发:

> curl -X POST http://127.0.0.1:8888/login
new login logic!

 

路径检查

首先是判断传入的path是否为一个目录,(结尾为/会被认为是一个目录)
如果是目录,并且存在一个有效的index参数,则会将index拼接到path后边。
也就是大概这样的操作:

send(ctx, './public/', {
  index: 'index.js'
})

// ./public/index.js

 

resolve-path 是一个用来处理路径的包,用来帮助过滤一些异常的路径,类似path//file/etc/XXX 这样的恶意路径,并且会返回处理后绝对路径。

isHidden用来判断是否需要过滤隐藏文件。
因为但凡是.开头的文件都会被认为隐藏文件,同理目录使用.开头也会被认为是隐藏的,所以就有了isHidden函数的实现。

其实我个人觉得这个使用一个正则就可以解决的问题。。为什么还要分割为数组呢?

function isHidden (root, path) {
  path = path.substr(root.length)

  return new RegExp(`${sep}\.`).test(path)
}

 

已经给社区提交了PR

注册路由的监听

上述全部是关于实例化Router时的一些操作,下面就来说一下使用最多的,注册路由相关的操作,最熟悉的必然就是router.getrouter.post这些的操作了。
但实际上这些也只是一个快捷方式罢了,在内部调用了来自Routerregister方法:

Router.prototype.register = function (path, methods, middleware, opts) {
  opts = opts || {}

  let router = this
  let stack = this.stack

  // support array of paths
  if (Array.isArray(path)) {
    path.forEach(function (p) {
      router.register.call(router, p, methods, middleware, opts)
    })

    return this
  }

  // create route
  let route = new Layer(path, methods, middleware, {
    end: opts.end === false ? opts.end : true,
    name: opts.name,
    sensitive: opts.sensitive || this.opts.sensitive || false,
    strict: opts.strict || this.opts.strict || false,
    prefix: opts.prefix || this.opts.prefix || '',
    ignoreCaptures: opts.ignoreCaptures
  })

  if (this.opts.prefix) {
    route.setPrefix(this.opts.prefix)
  }

  // add parameter middleware
  Object.keys(this.params).forEach(function (param) {
    route.param(param, this.params[param])
  }, this)

  stack.push(route)

  return route
}

 

该方法在注释中标为了 private 但是其中的一些参数在代码中各种地方都没有体现出来,鬼知道为什么会留着那些参数,但既然存在,就需要了解他是干什么的
这个是路由监听的基础方法,函数签名大致如下:

Param Type Default Description
path String/Array[String] - 一个或者多个的路径
methods Array[String] - 该路由需要监听哪几个METHOD
middleware Function/Array[Function] - 由函数组成的中间件数组,路由实际调用的回调函数
opts Object {} 一些注册路由时的配置参数,上边提到的strictsensitiveprefix在这里都有体现

可以看到,函数大致就是实现了这样的流程:

  1. 检查path是否为数组,如果是,遍历item进行调用自身
  2. 实例化一个Layer对象,设置一些初始化参数
  3. 设置针对某些参数的中间件处理(如果有的话)
  4. 将实例化后的对象放入stack中存储

所以在介绍这几个参数之前,简单的描述一下Layer的构造函数是很有必要的:

function Layer(path, methods, middleware, opts) {
  this.opts = opts || {}
  this.name = this.opts.name || null
  this.methods = []
  this.paramNames = []
  this.stack = Array.isArray(middleware) ? middleware : [middleware]

  methods.forEach(function(method) {
    var l = this.methods.push(method.toUpperCase());
    if (this.methods[l-1] === 'GET') {
      this.methods.unshift('HEAD')
    }
  }, this)

  // ensure middleware is a function
  this.stack.forEach(function(fn) {
    var type = (typeof fn)
    if (type !== 'function') {
      throw new Error(
        methods.toString() + " `" + (this.opts.name || path) +"`: `middleware` "
        + "must be a function, not `" + type + "`"
      )
    }
  }, this)

  this.path = path
  this.regexp = pathToRegExp(path, this.paramNames, this.opts)
}

 

layer是负责存储路由监听的信息的,每次注册路由时的URL,URL生成的正则表达式,该URL中存在的参数,以及路由对应的中间件。
统统交由Layer来存储,重点需要关注的是实例化过程中的那几个数组参数:

  • methods
  • paramNames
  • stack

methods存储的是该路由监听对应的有效METHOD,并会在实例化的过程中针对METHOD进行大小写的转换。
paramNames因为用的插件问题,看起来不那么清晰,实际上在pathToRegExp内部会对paramNames这个数组进行push的操作,这么看可能会舒服一下pathToRegExp(path, &this.paramNames, this.opts),在拼接hash结构的路径参数时会用到这个数组
stack存储的是该路由监听对应的中间件函数,router.middleware部分逻辑会依赖于这个数组

压缩的开启与文件夹的处理

在上边的这一坨代码执行完以后,我们就得到了一个有效的路径,(如果是无效路径,resolvePath会直接抛出异常)
接下来做的事情就是检查是否有可用的压缩文件使用,此处没有什么逻辑,就是简单的exists操作,以及Content-Encoding的修改 (用于开启压缩)

后缀的匹配:

if (extensions && !/.[^/]*$/.exec(path)) {
  const list = [].concat(extensions)
  for (let i = 0; i < list.length; i++) {
    let ext = list[i]
    if (typeof ext !== 'string') {
      throw new TypeError('option extensions must be array of strings or false')
    }
    if (!/^./.exec(ext)) ext = '.' + ext
    if (await fs.exists(path + ext)) {
      path = path + ext
      break
    }
  }
}

 

可以看到这里的遍历是完全按照我们调用send是传入的顺序来走的,并且还做了.符号的兼容。
也就是说这样的调用都是有效的:

await send(ctx, 'path', {
  extensions: ['.js', 'ts', '.tsx']
})

 

如果在添加了后缀以后能够匹配到真实的文件,那么就认为这是一个有效的路径,然后进行了break的操作,也就是文档中所说的:First found is served.

在结束这部分操作以后会进行目录的检测,判断当前路径是否为一个目录:

let stats
try {
  stats = await fs.stat(path)

  if (stats.isDirectory()) {
    if (format && index) {
      path += '/' + index
      stats = await fs.stat(path)
    } else {
      return
    }
  }
} catch (err) {
  const notfound = ['ENOENT', 'ENAMETOOLONG', 'ENOTDIR']
  if (notfound.includes(err.code)) {
    throw createError(404, err)
  }
  err.status = 500
  throw err
}

 

path

在函数头部的处理逻辑,主要是为了支持多路径的同时注册,如果发现第一个path参数为数组后,则会遍历path参数进行调用自身。
所以针对多个URL的相同路由可以这样来处理:

router.register(['/', ['/path1', ['/path2', 'path3']]], ['GET'], ctx => {
  ctx.body = 'hi there.'
})

 

这样完全是一个有效的设置:

> curl http://127.0.0.1:8888/
hi there.
> curl http://127.0.0.1:8888/path1
hi there.
> curl http://127.0.0.1:8888/path3
hi there.

 

一个小彩蛋

可以发现一个很有意思的事情,如果发现当前路径是一个目录以后,并且明确指定了format,那么还会再尝试拼接一次index
这就是上边所说的那个彩蛋了,当我们的public路径结构长得像这样的时候:

└── public
    └── index
        └── index # 实际的文件 hello

 

我们可以通过一个简单的方式获取到最底层的文件数据:

router.get('/surprises', async ctx => {
  await send(ctx, '/', {
    root: './public',
    index: 'index'
  })
})

// > curl http://127.0.0.1:12306/surprises
// hello

 

这里就用到了上边的几个逻辑处理,首先是trailingSlash的判断,如果以/结尾会拼接index,以及如果当前path匹配为是一个目录以后,又会拼接一次index
所以一个简单的/加上index的参数就可以直接获取到/index/index
一个小小的彩蛋,实际开发中应该很少会这么玩

methods

而关于methods参数,则默认认为是一个数组,即使是只监听一个METHOD也需要传入一个数组作为参数,如果是空数组的话,即使URL匹配,也会直接跳过,执行下一个中间件,这个在后续的router.routes中会提到

最终的读取文件操作

最后终于来到了文件读取的逻辑处理,首先就是调用setHeaders的操作。

因为经过上边的层层筛选,这里拿到的path和你调用send时传入的path不是同一个路径。
不过倒也没有必要必须在setHeaders函数中进行处理,因为可以看到在函数结束时,将实际的path返回了出来。
我们完全可以在send执行完毕后再进行设置,至于官方readme中所写的and doing it after is too late because the headers are already sent.
金沙官网线上,这个不需要担心,因为koa的返回数据都是放到ctx.body中的,而body的解析是在所有的中间件全部执行完以后才会进行处理。
也就是说所有的中间件都执行完以后才会开始发送http请求体,在此之前设置Header都是有效的。

if (setHeaders) setHeaders(ctx.res, path, stats)

// stream
ctx.set('Content-Length', stats.size)
if (!ctx.response.get('Last-Modified')) ctx.set('Last-Modified', stats.mtime.toUTCString())
if (!ctx.response.get('Cache-Control')) {
  const directives = ['max-age=' + (maxage / 1000 | 0)]
  if (immutable) {
    directives.push('immutable')
  }
  ctx.set('Cache-Control', directives.join(','))
}
if (!ctx.type) ctx.type = type(path, encodingExt) // 接口返回的数据类型,默认会取出文件后缀
ctx.body = fs.createReadStream(path)

return path

 

以及包括上边的maxageimmutable都是在这里生效的,但是要注意的是,如果Cache-Control已经存在值了,koa-send是不会去覆盖的。

middleware

middleware则是一次路由真正执行的事情了,依旧是符合koa标准的中间件,可以有多个,按照洋葱模型的方式来执行。
这也是koa-router中最重要的地方,能够让我们的一些中间件只在特定的URL时执行。
这里写入的多个中间件都是针对该URL生效的。

P.S. 在koa-router中,还提供了一个方法,叫做router.use,这个会注册一个基于router实例的中间件

本文由金沙官网线上发布于Web前端,转载请注明出处:koa源码阅读[3]-koa-send与它的衍生(static)

您可能还会对下面的文章感兴趣: