Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

HTTP的100状态码及相关思考

  当我们请求一个资源时,在浏览器无法得知的情况下,也许服务器已经响应了“HTTP/1.1 100 Continue”。这个状态是XHR对象无法监测的,响应这个状态码对客户端不会有任何影响,而且即便是跨域也可以响应这个状态码,不需要添加任何CORS相关的响应头。

这是一个神奇的状态码

  居然无视跨域安全策略,这也太神奇了吧?其实这个100状态属于连接状态,不属于数据通讯状态,所以不被纳入跨域安全策略的管辖。

与XHR对象无缘

  XHR对象无法监测100这个状态码,所以它不需要跨域安全策略也依然是安全的。但这也直接导致了它与XHR是没有缘分的,无法在XHR对象中使用100状态码相关的服务。包括在HTTP请求头中附加Expect: 100-Continue字段目前也是被禁止的。

更优秀的通讯设计

  既然说100状态码属于连接阶段的状态码,那就意味着即使服务器响应了100状态码,客户端也依然可以继续与之通讯。假如现在有个上传文件的需求,这样的通讯设计是不是更好呢?
  1. 建立TCP连接
  2. 客户端发送HTTP头
  3. 服务器通过Cookie等信息验证用户权限
  4. 如果验证通过则:
    1. 响应 100 状态码
    2. 客户上传文件内容
  5. 否则:
    1. 响应 403 之类的状态码

与CGI模式无缘

  其实很多Web服务器程序都是以CGI模式工作的,比如PHP可以通过$_POST获取POST过来的数据,通过$_FILES获取上传过来的文件。也就是说,是数据部分全部发送完成后,PHP程序才开始处理。但实际上只要有HTTP请求头就可以对很多东西做先行判断,很多时候上传数据部分是多余的。像NodeJS这种非CGI模式的Web服务器程序,处理这类问题简直不是个事儿,这也是NodeJS受欢迎的原因之一。

替代方案

  它既与XHR对象无缘,又与CGI模式无缘,所以在Web开发中基本没法使用。但即使肉身不在,其灵魂也可以不灭。我们可以使用其它替代方案来设计出类似的通讯模式。依然是上传文件的问题,我们可以使用Keep-Alive解决。
  1. 建立TCP连接
  2. 客户端发起HEAD或OPTIONS请求
  3. 服务器通过Cookie等信息验证用户权限
  4. 如果验证通过则:
    1. 响应 2xx 状态码
    2. 客户端发起文件上传的POST或PUT请求
  5. 否则:
    1. 响应 403 之类的状态码
  我们做了和先前类似的事情,但模拟毕竟只是模拟,总是存在一些缺陷。其实这个替代方案在我看来一点都不漂亮,虽然使用Keep-Alive可以避免TCP连接重复创建,但在上面的 4.2 步中,发起文件上传请求的HTTP头部分实际上是多余的,如果头比较大的话通信负担就会加重。不过这也许是我个人太完美主义了,实际运用中这点通讯成本是完全可以忽略不计的。

总结

  也许100状态码相关的东西不属于Web领域,但它确实是HTTP的东西。即使这些规范本身无法使用,我们也可以学习它们的概念,在我们现有的技术中寻找替代方案来实现这些概念。

网名:
54.198.108.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^