美文网首页
URL 和 HTTP 报文详解

URL 和 HTTP 报文详解

作者: 凯俊 | 来源:发表于2019-03-26 23:12 被阅读0次

    URL 的语法

    <scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

    组件 描述 默认值
    方案 访问服务器以获取资源时需要使用哪种协议
    用户 某些方案访问资源时需要的用户名 匿名
    密码 用户名后面可能要包含的密码,中间由冒号分隔 <E-mail 地址>
    主机 资源宿主服务器的主机名或点分IP地址
    端口 资源宿主服务器正在监听的端口号。很多方案都有默认端口号。 每个方案特有
    路径 服务器上资源的本地名,由一个斜杠/将其与前面的URL组件分隔开来。路径组件的语法是与服务器和方案有关的。
    参数 某些方案会用这个组件来指定输入参数。参数为名/值对。URL中可以包含多个参数字段,它们相互之间以及与路径的其余部分之间用分号;分隔
    查询 某些方案会用这个组件传递参数以激活应用程序。查询组件的内容没有通用格式。用字符?将其与URL的其余部分分隔开来。
    片段 一小片或一部分资源的名字。引用对象时,不会将frag字段传送给服务器;这个字段是在客户端内部使用的。通过字符#将其与URL的其余部分分隔开来。

    报文的语法

    请求报文

    <method> <request-URL> <version>
    <headers>
    
    <entity-body>
    
    POST /api/sign/register.json HTTP/1.1
    Host: dev.zhiaotech.com:8005
    Content-Length: 13
    Accept: */*
    Origin: http://dev.zhiaotech.com:8004
    DNT: 1
    Content-Type: application/json
    Connection: keep-alive
    
    {"name":"xx"}
    

    响应报文

    <version> <status-code> <reason-phrase>
    <headers>
    
    <entity-body>
    
    HTTP/1.1 200 OK
    Server: nginx/1.10.3 (Ubuntu)
    Content-Type: application/json
    Transfer-Encoding: chunked
    Access-Control-Allow-Origin: http://dev.zhiaotech.com:8004
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Headers: Origin, Content-Type, Cookie, Accept
    Access-Control-Allow-Methods: GET, POST, PATCH, PUT, OPTIONS
    Cache-Control: no-cache, private
    Date: Wed, 27 Feb 2019 00:20:44 GMT
    Set-Cookie: laravel_session=4Q8jPlqCd0Ex9GOa8Nujblgaun8sNs; 
    expires=Wed, 27-Feb-2019 02:20:44 GMT; Max-Age=7200; path=/; httponly
    Proxy-Connection: keep-alive
    
    {"data":"","code":1001,"msg":"未登录"}
    
    • 方法(method)

      客户端希望服务器对资源执行的动作。是一个单独的词,比如GET、HEAD、或POST等等。

    • 请求URL(request-URL)

      命名了所请求资源,或者URL路径组件的完整URL。

    • 版本(version)

      报文所使用的 HTTP 版本,其格式看起来是这样的:
      HTTP/<major>.<minor>
      其中major和minor都是整数

    • 状态码(status-code)

      为三位数字,这三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别(“成功”、“出错”等)。

    • 原因短语(reason-phrase)

      数字状态码的可读版本,包含行终止序列之前的所有文本。原因短语只对人类有意义。

    • 首部(header)

      可以有零个或多个首部,每个首部都包含一个名字,后面跟着一个冒号:,然后是一个可选的空格,接着是一个值,最后是一个CRLF。首部是由一个空行CRLF结束的,表示了首部列表的结束和实体主体部分的开始。有些HTTP版本,比如HTTP/1.1,要求有效的请求或相应报文中必须包含特定的首部。

    • 实体的主体部分(entity-body)

      实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主题部分,有时,报文只是以一个CRLF结束。

    起始行

    请求行

    包含了一个方法和一个请求URL,请求行中还包含HTTP的版本,在HTTP/1.0之前,并不要求请求行中包含HTTP版本号。

    响应行

    包含HTTP版本,数字状态码,以及描述操作状态的文本形式的原因短语。

    方法

    常用的HTTP方法有以下7种,注意,有些方法的请求报文中有主体,有的则没有。

    方法 描述 是否包含主体
    GET 从服务器获取一份文档
    HEAD 只从服务器获取文档的首部
    POST 向服务器发送需要处理的数据
    PUT 将请求的主体部分存储在服务器上
    TRACE 对可能经过代理服务器传送到服务器上去的报文进行追踪
    OPTIONS 决定可以在服务器上执行哪些方法
    DELETE 从服务器上删除一份文档

    状态码

    通过三位数字代码对不同状态码进行分类,200到299之间的状态码表示成功。300到399之间的代码表示资源已经被移走了。400到499之间的代码表示客户端的请求出错了。500到599之间的代码表示服务器出错了。

    整体范围 已定义范围 分类
    100 ~199 100 ~ 101 信息提示
    200 ~ 299 200 ~ 206 成功
    300 ~ 399 300 ~ 305 重定向
    400 ~ 499 400 ~ 415 客户端错误
    500 ~ 599 500 ~ 505 服务端错误

    原因短语

    原因短语和状态码是成对出现的。原因短语是状态码的可读版本,应用程序开发者将其传送给用户,用以说明在请求期间发生了什么情况。

    HTTP规范并没有提供任何硬性规定,要求原因短语以何种形式出现。

    首部

    首部分类

    HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下几类。

    • 通用首部

      既可以出现在请求报文中,也可以出现在响应报文中。

    • 请求首部

      提供更多有关请求的信息。

    • 响应首部

      提供更多有关响应的信息。

    • 实体首部

      描述主题的长度和内容,或者资源自身。

    • 扩展首部

      规范中没有定义的新首部。

    常见的首部实例

    首部实例 描述
    Date:Tue,3Oct 1997 02:16:03 GMT 服务器产生响应的日期
    Content-Length:15040 实体的主体部分包含了15040字节的数据
    Content-Type:image/gif 实体的主体部分是一个GIF图片
    Accept:image/gif, image/jpeg, text/html 客户端可以接受GIF图片和JPEG图片以及HTML

    首部延续行

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

    HTTP/1.0 200 OK
    Content-Type: image/gif
    Content-Length: 8572
    Server: Test Server
        Version 1.0
    

    在这个例子中,Server 首部的值 Test Server Version 1.0 被划分成了多个延续行。

    相关文章

      网友评论

          本文标题:URL 和 HTTP 报文详解

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