美文网首页
《HTTP权威指南》笔记:第三章-HTTP报文

《HTTP权威指南》笔记:第三章-HTTP报文

作者: 前端艾希 | 来源:发表于2021-11-13 21:00 被阅读0次

    一、报文的组成部分

    HTTP报文是简单的格式化数据块,由三部分组成:起始行(start line),首部(header),包含数据的主体(body)。

    1.1 报文语法

    所有的HTTP报文都可以分为两类:请求报文(request message)和响应报文(response message)。

    这是请求报文的格式:

    <method> <request-url> <version>
    <headers>
    
    <entity-body>
    

    这是响应报文的格式:

    <version> <status> <reason-phrase>
    <headers>
    
    <entity-body>
    
    • method,客户端希望服务器对资源执行的动作。
    • request-url,命名所请求资源,或者URL路径组件的完整URL
    • version,报文所使用的HTTP版本,格式为:HTTP/<major>.<minor>
    • status-code,使用三位数字描述请求过程中发生的情况。
    • reason-phrase,数字状态码的可读版本。
    • header,可以有零个或者多个首部,格式为:<key>:[space]<value>[,<value>...]CRLF,整个首部是由一个CRLF结束的。
    • entity-body,包含由任意数据组成的数据块,有时仅仅是一个CRLF结束符。

    1.2 起始行

    所有的HTTP报文都以一个起始行作为开始。请求报文的起始行说明了要做些什么,响应报文的起始行则说明发生了什么。

    • 请求行,请求服务器对资源进行一些操作,包含了一个方法、一个请求URLHTTP的版本,在HTTP/1.0之前,并不要求请求行中包含版本号。
    • 响应行,响应行包含了响应报文使用的HTTP版本、数字状态码以及描述操作状态的原因短语。

    1.3 首部

    HTTP首部字段向请求和响应报文中添加了一些附加信息,本质上说,它们只是一些key:value的列表。

    1.3.1 首部分类

    HTTP首部可以分为以下几类:

    • 通用首部,既可以出现在请求报文中也可以出现在响应报文中。
    • 请求首部,提供更多有关请求的信息。
    • 响应首部,提供更多有关响应的信息。
    • 实体首部,描述主题的长度和内容,或者资源本身。
    • 扩展首部,规范中没有定义的首部。

    1.3.2 首部延续行

    长的首部可以分为多行提高可读性,多出来的每行至少有一个空格或者制表符,例如:

    // 长首部
    Server:Test Server Version 1.0
    
    // 首部延续行
    Server:Test Server
        Version 1.0
    

    1.4 实体

    实体的主体是HTTP报文的载荷,也就是HTTP要传输的内容,实体是可选的。

    HTTP报文可以承载很多类型的数据:图片,视频,HTML文档,Javascript脚本,电子邮件等。

    二、方法

    并不是每个服务器都实现了所有规范中的方法

    2.1 安全方法

    HTTP规范定义了gethead为安全方法,这意味着gethead不会在服务器产生动作。

    2.2 HEAD

    head方法只返回资源首部,使用head可以:

    • 在不获取资源的情况下了解资源情况(content-typecontent-length);
    • 验证资源是否存在;
    • 验证资源是否被修改。

    2.3 PUT

    put方法的语义就是:让服务器用请求的主体部分创建一个用请求主体部分创建一个由所请求的URL命名的新文档,如果已经存在,那么替换。

    2.4 TRACHE

    trace方法允许客户端在最终将请求发送到服务器时,看看它变成什么样子了。该方法一般用来验证请求是否按照预期穿过了某些代理。trace请求不能携带实体。

    2.4 OPTIONS

    options方法可以询问服务器支持哪些功能,或者可以询问针对特定资源所支持的功能。

    2.5 DELETE

    delete方法就是请求服务器删除请求URL所指定的资源,当然,服务器不一定会这么做,因为HTTP规范允许服务器在不告知客户端的情况下撤销请求。

    三、状态码

    状态码为客户端提供了一种理解事物处理结果的便捷方式。

    3.1 100 ~ 199 信息性状态码

    下面是HTTP/1.1已定义的信息性状态码:

    • 100 continue,说明已经收到了请求的初始部分,请客户端继续。
    • 101 switching protocols,说明服务器正在根据客户端指定,将协议切换成update首部指定的协议。

    100 continue的目的是希望客户端在向服务器发送实体时先询问服务器是否接受这个实体,即客户端需要发送一个携带100 continueexpect首部,这个首部一般用在要传送大文件时,并且客户端不应该一直等待服务器返回100 continue后才发送实体,超过一定时间后,客户端应该直接发送实体。

    3.2 200 ~ 299 成功状态码

    下面列出了已定义的成功状态码:

    • 200 ok
    • 201 created,用于响应创建对象的请求,比如putlocation为新创建对象的引用。
    • 202 accept,请求已被接受,但是还未执行操作,实体部分应当包含对执行情况的描述,比如完成时间等信息。
    • 203 non-authoritative information,请求的首部并非来自源端服务器,假设你的请求在请求链上被某个资源服务器响应了,可能返回这个状态码。
    • 204 no content,没有实体的响应。
    • 205 reset content,告诉浏览器清除页面中所有的HTML表单元素。
    • 206 partical content,成功执行了一个range请求。

    3.3 300 ~ 399 重定向状态码

    重定向状态码要么时告知客户端使用替代位置来访问他们所感兴趣的资源(重定向),要么就提供一个替代的响应而不是资源的内容(缓存)。

    • 300 multiple choices,客户端的一个请求实际指向多个资源时,服务器会返回这个状态码以及location列表让客户端选择。
    • 301 moved permanently,永久重定向,location中为现在资源所处的URL
    • 302 found,临时重定向,location中为临时定位资源,并且会把post改为get请求。
    • 303 see other,临时重定向,并且会把post改为get请求。
    • 304 not modified,资源未修改。
    • 305 use proxy,用来说明必须通过代理访问,代理放在location
    • 307 temporary redirect,临时重定向,不过不会修改请求方法,如果是以post请求,那么新的请求就是post

    其中302303307都是临时重定向,造成这种结果的原因是HTTP/1.1兼容HTTP/1.0。因为HTTP/1.0希望客户端收到302后,如果原请求是post那么新的请求将被改为getHTTP/1.1则用303307分别实现了修改请求方法和不修改请求方法的功能,而将302保留给HTTP/1.0以保证兼容性。

    3.4 400 ~ 499 客户端错误状态码

    已定义客户端错误状态码:

    • 400 bad request,错误的请求。
    • 401 unauthorized,未认证,和关于认证的首部一起返回。
    • 402 payment required,保留。
    • 403 forbidden,服务器拒绝了,并且不想告诉你拒绝的理由
    • 404 not found,资源或者程序不存在,通常会在实体中告诉客户端具体问题。
    • 405 method not allowed,该方法不被允许,在allowed首部中应该说明允许的方法。
    • 406 not acceptable,服务器没有该URL相关的指定类型的资源,即客户端的首部的accept字段中包含的类型服务器没有。
    • 407 proxy authentication required,要求对资源进行认证的代理服务器。
    • 408 request timeout,如果客户端长时间未完成该请求,那么可以发送此状态码并关闭链接。
    • 409 conflict,请求可能在资源上引发冲突。
    • 410 gone,表示服务器曾经拥有该资源,但是现在没有了。
    • 411 lenth required,表示服务器需要客户端带上content-length首部。
    • 412 precondition failed,客户端包含了expect首部的请求成为条件请求,当条件不满足时,返回该状态码。
    • 413 request entity too large,客户端发送的实体超过了服务器要求的长度。
    • 414 request uri too long,客户端请求的URL太长了!
    • 415 unsupported media type,服务器无法理解的媒体类型。
    • 416 request range not satisfiable,请求指定的范围不满足。
    • 417 expectation failed,请求的expect无法满足。

    3.5 500 ~ 599 服务器错误状态码

    已定义的服务器错误状态码:

    • 500 internal server error,服务器内部错误。
    • 501 not implement,超出服务器能力范围。
    • 502 bad gateway,代理或者网关无法连接到下一级网关(父级网关)。
    • 503 service unavailabe,服务器现在不可用,但是未来可能可用,可以返回一个首部retry-after
    • 504 gateway timeout,和408 request timeout差不多,但是超时问题出现在代理或者网关上
    • 505 http version not supported,服务器不支持或者不想支持该协议版本。

    四、首部

    4.1 通用首部

    • connection,允许客户端和服务器指定与连接有关的选项。
    • date,报文的创建时间。
    • mime-versionmime类型的版本。
    • trailer,分块传输编码。
    • transfer-encoding,编码方式。
    • update,发送端想升级版本或者协议。
    • via,报文经由的节点。
    • cache-control,缓存指示。

    4.2 请求首部

    服务器可以根据请求首部给出的客户端信息为客户端提供更好的响应。

    4.2.1 Accept首部

    accept首部告诉服务器客户端想要什么和不想要什么,服务器需要根据客户端的要求发送符合要求的内容。

    • accpet,允许的媒体类型。
    • accept-charset,允许的字符集。
    • accept-encoding,允许的编码方式。
    • accept-language,允许的语言。
    • te,允许的扩展传输编码。

    4.2.2 条件请求首部

    为请求加限制,服务端可以根据限制条件满足与否发送不同的内容。

    • expect,期望服务器的行为,例如:100 continue
    • if-match,如果实体标记与文档当前的的实体标记相匹配,就获取这份文档。
    • if-modified-since,除非在某个指定的日期之后资源被修改过,否则限制这个请求。
    • if-none-match,如果提供的实体标记与当前文档的实体标记不相符,就获取文档。
    • if-range,允许对文档的某个范围进行条件请求。
    • if-unmodified-since,除非在某个指定日期之后资源没有被修改过,否则就限制这个请求。
    • range,如果服务器支持范围请求,就请求资源的指定范围。

    4.2.3 安全请求首部

    • authorization,客户端自身认证数据。
    • cookie,客户端令牌。
    • cookie2,用来说明客户端支持的cookie版本。

    4.2.4 代理请求首部

    • max-forward,将请求转发给其他代理或者网关的最大次数。
    • proxy-authorization,与客户端认证一样。
    • proxy-connection,与客户端一样。

    4.3 响应首部

    4.3.1 协商首部

    • accpet-ranges,对此资源来说服务器可接受的范围类型。
    • vary

    4.3.2 安全响应首部

    • proxy-authenticate,来自代理的对客户端的质询列表。
    • set-cookie,在客户端写入cookie
    • set-cookie2,与set-cookie类似。
    • www-authenticate,来自服务器对客户端的质询列表。

    4.4 实体首部

    4.4.1 信息性首部

    • allow,列出了可以对此实体执行的请求方法。
    • location,告知客户端资源的位置(URL)。

    4.4.2 内容首部

    • content-base,解析实体中相对URL时的基础URL
    • content-encoding,对实体执行的任意编码方式。
    • content-language,理解实体最适宜的语言。
    • content-length,实体的大小。
    • content-location,实体所处的位置。
    • content-MD5,实体的md5校验和
    • content-range,在整个资源中此实体表示的字节范围。

    4.4.3 实体缓存首部

    • etag,与此实体相关的实体标记。
    • expires,缓存的失效时间。
    • last-modified,实体最后一次被修改的日期和时间。

    参考文献

    [1]《HTTP权威指南》

    相关文章

      网友评论

          本文标题:《HTTP权威指南》笔记:第三章-HTTP报文

          本文链接:https://www.haomeiwen.com/subject/mlizzltx.html