在做一个 RESTFul API 的认证时，碰到一个问题，花了一个半小时才搞明白。
认证由于没上 https(内部用), 所以最好用类似 amazon 早前使用的 hmac-signature ，这样至少可以对 request 的 Date 进行限制，刚好使用的 API 框架 restify 的自带插件支持 http signature, 只是稍稍复杂点，于是整套认证逻辑就写了几十行代码，就可以着手进行验证，这套 API 设计时文档使用了 Swagger , 可以很方便得在 swagger.yaml 要求加上 Date Header 和 Authorization Header ， swagger-ui 那边就能直接在浏览器上进行这个认证的验证测试。
然而，测试结果发现请求头里需要的 Date header 消失了，却没有任何提示。随后在本地写测试代码，却没有问题，所以怀疑是 swagger-ui 这边有 bug，心痒难绕，便一层层找依赖看代码，打日志执行调试，日志一直打到最后执行添加头的地方，却没有发现任何异常，这个 Date header 执行时就像凭空消失了一样。上 github 在 issues 里搜索，也找不到相关信息。
正无所适从时，修改发现，date 头改名为 datee 或其它，就能正常在 swagger-ui 的请求头里出现，当时想了一下，莫非是 date 头被浏览器禁止了？ google 了一下，果然如此，浏览器里使用 XMLHttpRequest 时，date 头是被禁止的！ 具体可看 MDN。 标准里已有写明。于是问题解决。
这事的教训是:
- 不熟悉的领域出了问题，简单查看代码以及 issues 没有找到原因时，就可以先怀疑是不是自己不熟悉这个领域的标准。去查看标准或者询问相关领域熟悉的人。现在想来，如果有人知道这点，那么问一句的时间就能解决。
- 执行最好有明确反馈。标准里规定请求出现这些被禁止的头就会直接中断请求，然而标准也说了标准只是行业建议，不是具体实现。如 MDN 上所述，在 XMLHttpRequest 里设置头时，这些被禁止的头标志是被浏览器(user agent) 完全控制的，而浏览器表现的行为是直接过滤掉这些头标志，却不给提示，这会让不了解的人感到困扰。
- 实际上，这不算是什么问题，毕竟本地测试代码已经通过了，有问题的不过是文档页面上的接口测试使用不了认证，不能让使用者在浏览 API 文档时直接使用接口调试功能。这个问题可以记录并延后处理，优先来实现更紧急的部分。一心一意是好习惯，但做工程，团队协作，还是要统筹一下。回想起来，当时对这个问题没解决是抱着一种很焦虑的心态， 那么，记录，放入 todolist，并评估，这样应该能缓解很多。
