HTTP协议

四个决策树让你彻底掌握 HTTP 状态码

你好,我是看山。

众所周知,每一个 HTTP 响应都会带有一个 HTTP 状态码(HTTP Status Code),是用来表示 HTTP 服务器响应状态的代码。它由 RFC 2616 规范定义的,并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918 等规范扩展。作为 web 开发者,平时经常 200、301、302、404、500、503 等。最近正在开发一些对外的接口(公司内部各系统间互相调用的接口,也算是内部 Open API 吧),接口调用失败时需要返回一些状态码,考虑借用 HTTP 状态码的含义,可以让调用方通过状态码就能够大体知道出了什么问题,不用彼此重新约定不熟悉的编码规则,方便沟通及错误定位。自认为想法不错,但是在实际编写中遇到了问题,这个多的状态码该怎么用?就用这个机会好好学习下什么场景用什么状态码,也通过本文记录一下 HTTP 状态码的内容。在本文中借 Michael Kropat 的 《Choosing an HTTP Status Code —

HTTP请求方法

HTTP请求方法

HTTP方法是启动请求字符串中的必需参数。一种方法可以称为请求类型,并且基于此类型,必须在服务器上执行某些操作并将响应返回给客户端。该方法的名称区分大小写,并且通常是一个简短的单词,由英文大写字母组成。

接收请求时,服务器尝试确定请求的方法,如果失败,则返回带有代码501和短语的响应消息Not Implemented。如果服务器已定义方法,但是无法将其应用于请求的资源,则返回带有代码405和短语的响应消息Method Not Allowed了解有关HTTP响应状态代码的更多信息。如果出现这两个选项中的任何一个,则服务器需要在返回响应时添加标头Allow 并列出服务器支持的所有方法。…

一文串联 HTTP / [0.9 | 1.0 | 1.1 | 2 | 3]

1989 年,万维网诞生之后,HTTP 迅速成为主导世界的应用层协议。在今天,几乎任何场景都或多或少用到了 HTTP 协议。

在 30 多年的历史中,HTTP 协议本身有比较大的发展,同时,还有一些重大的变动也在酝酿之中。这些演化使得这个协议的表现力更强,性能更好,更能满足日新月异的应用需求。本文就来回顾和展望一下 HTTP 的历史和未来。

  • HTTP/0.9
  • HTTP/1.0
  • HTTP/1.1
  • HTTP/2
  • HTTP/3

HTTP/0.9

HTTP/0.9 诞生于 1991 年,是 HTTP 协议的最初版,构造十分简单:

  • 请求端只支持 GET 请求
  • 响应端只能返回 HTML 文本数据
GET /index.html
<html>
  <body>
    Hello World
  </body>
</html>

请求示意图如下:

            

轻松理解HTTP缓存策略

上一篇文章我写了koa-static的源码解析,其中用到了HTTP的缓存策略,给返回的静态文件设置了一些缓存的头,比如Cache-Control之类的。于是我就跟朋友讨论了一下HTTP的缓存策略:

朋友说:“HTTP里面控制缓存的头(header)太多了,啥Cache-ControlETagLast-Modified,一大堆,乱七八糟的,而且之间逻辑关系不强,要掌握基本靠背!”

我有点惊讶:“为什么要去背这个呢?所有的技术都是为了解决问题而存在的,不了解问题而去单纯的学习技术,去,背,去,死记,确实很枯燥,而且效果不好。HTTP缓存策略只是为了解决客户端和服务端信息不对称的问题而存在的,客户端为了加快速度会缓存部分资源,但是下次请求时,客户端不知道这个资源有没有更新,服务端也不知道客户端缓存的是哪个版本,不知道该不该再返回资源,其实就是一个信息同步问题,HTTP缓存策略就是来解决这个问题的。如果我们跳出这种纯粹的技术思维,我们会发现生活中这种信息同步问题也很常见。而我们解决这些问题的思路很多时候都是司空见惯了,如果从这个角度来说,这个问题就很好理解!”

于是我给他讲了一个我小时候租光碟看奥特曼的故事。…

            

实践带你了解–http缓存

这次文章为了了解http缓存的机制,自己搭建nginx和设置nginx配置
网上的文章其实有很多,但是大部分都是文字表达,缓存这块又比较偏向理论,导致我一开始也是云里雾里的

所以这次我通过截图和步骤图来说明,并且进行文字补充, 不喜欢看文字的话其实看图片就行啦

以下每次截图都是无痕模式的…

                

HTTP/2服务器推送已死

HTTP/2附带的热门功能之一是PUSH帧。主要思想是,如果服务器可以预测客户端可能要发出的请求,则服务器可以抢先向客户端发送请求/响应对并预热其缓存。

这是我很久以来一直很感兴趣的功能。我认为API使缓存无效和预热缓存,消除对复合请求的需求(我认为这是一种技巧,尽管有时是必要的)非常有用。

为了帮助推进这个想法,我编写Internet Draft,以使API客户端告诉服务器他们希望推送哪些资源,我构建了具有一流,深度集成的Push支持并添加了支持的Node.js框架。为Prefer-PushKetting。…

        

HTTP/3 都来了,你却还在用 HTTP/1.1?

2015 年 HTTP/2 标准发表后,大多数主流浏览器也于当年年底支持该标准。此后,凭借着多路复用、头部压缩、服务器推送等优势,HTTP/2 得到了越来越多知名互联网公司的青睐。就在大家刚刚为了解了 HTTP/2 新特性而舒口气儿的时候,HTTP/3 却又紧锣密鼓地准备着了。今天就跟大家聊一聊这第三代 HTTP 技术。…