跳到主要内容

5. 请求 (Request)

5 Request

client 发往 server 的 request message 在该 message 的第一行中包含要应用到 resource 的 method, resource 的 identifier, 以及正在使用的 protocol version.

    Request       = Request-Line              ; Section 5.1
                    *(( general-header        ; Section 4.5
                     | request-header         ; Section 5.3
                     | entity-header ) CRLF)  ; Section 7.1
                    CRLF
                    [ message-body ]          ; Section 4.3

5.1 Request-Line

Request-Line 以 method token 开始, 后跟 Request-URI 和 protocol version, 并以 CRLF 结束. 各元素由 SP 字符分隔. 除最后的 CRLF 序列外, 不允许出现 CR 或 LF.

    Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

5.1.1 Method

Method token 表示要在 Request-URI 所标识 resource 上执行的方法. method 区分大小写.

   Method         = "OPTIONS"                ; Section 9.2
                  | "GET"                    ; Section 9.3
                  | "HEAD"                   ; Section 9.4
                  | "POST"                   ; Section 9.5
                  | "PUT"                    ; Section 9.6
                  | "DELETE"                 ; Section 9.7
                  | "TRACE"                  ; Section 9.8
                  | "CONNECT"                ; Section 9.9
                  | extension-method
   extension-method = token

resource 允许的方法列表可以在 Allow header field (第 14.7 节) 中指定. response 的 return code 始终会通知 client 某个 method 当前是否允许用于某个 resource, 因为允许的方法集合可以动态变化. 如果 origin server 知道该 method 但该 method 不允许用于所请求 resource, origin server SHOULD 返回 status code 405 (Method Not Allowed); 如果 origin server 不识别或未实现该 method, 则返回 501 (Not Implemented). 所有通用 server MUST 支持 GET 和 HEAD method. 所有其他 method 都是 OPTIONAL; 但是, 如果实现了上述 method, 它们 MUST 按第 9 节规定的相同语义实现.

5.1.2 Request-URI

Request-URI 是统一资源标识符 (Uniform Resource Identifier, 第 3.2 节), 标识 request 要应用到的 resource.

   Request-URI    = "*" | absoluteURI | abs_path | authority

Request-URI 的四种选项取决于 request 的性质. 星号 "*" 表示 request 不适用于特定 resource, 而适用于 server 本身, 并且只在所用 method 不一定适用于某个 resource 时才允许. 一个例子是:

   OPTIONS * HTTP/1.1

当 request 发往 proxy 时, REQUIRED 使用 absoluteURI 形式. 请求 proxy 转发该 request, 或从有效 cache 中服务它, 并返回 response. 注意, proxy MAY 将 request 转发给另一个 proxy, 或直接转发给 absoluteURI 指定的 server.

为避免 request loop, proxy MUST 能够识别自己的所有 server name, 包括任何 alias, local variation 和数字 IP 地址. 一个 Request-Line 示例为:

   GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

为允许在 HTTP 未来版本中所有 request 都过渡到 absoluteURI, 所有 HTTP/1.1 server MUST 接受 request 中的 absoluteURI 形式, 即使 HTTP/1.1 client 只会在发往 proxy 的 request 中生成这种形式.

authority 形式只由 CONNECT method 使用 (第 9.9 节).

Request-URI 最常见的形式用于标识 origin server 或 gateway 上的 resource. 在这种情况下, URI 的 absolute path MUST 作为 Request-URI 传输 (见第 3.2.1 节, abs_path), 且 URI 的 network location (authority) MUST 在 Host header field 中传输. 例如, 希望直接从 origin server 检索上述 resource 的 client 会与 host "www.w3.org" 的 80 端口建立 TCP connection, 并发送以下行:

   GET /pub/WWW/TheProject.html HTTP/1.1
   Host: www.w3.org

后跟 Request 的其余部分. 注意, absolute path 不能为空; 如果原始 URI 中不存在, 则 MUST 给出为 "/" (server root).

Request-URI 以第 3.2.1 节规定的格式传输. 如果 Request-URI 使用 "% HEX HEX" 编码 [42], origin server MUST 解码 Request-URI 以正确解释 request. server SHOULD 用适当 status code 响应无效 Request-URI.

transparent proxy 在向下一个 inbound server 转发收到的 Request-URI 时, MUST NOT 重写其中的 "abs_path" 部分, 除非如上所述把空 abs_path 替换为 "/".

  注意: "no rewrite" 规则防止 proxy 在 origin server 不正确地把非保留 URI 字符用于保留目的时改变 request 的含义.
  实现者应知道, 某些 HTTP/1.1 之前的 proxy 曾被发现会重写 Request-URI.

5.2 Request 标识的 Resource

Internet request 所标识的精确 resource 由同时检查 Request-URI 和 Host header field 确定.

不允许 resource 随请求 host 不同而不同的 origin server, 在确定 HTTP/1.1 request 标识的 resource 时 MAY 忽略 Host header field value. (但关于 HTTP/1.1 中 Host 支持的其他要求见第 19.6.1.1 节.)

会基于请求 host 区分 resource 的 origin server (有时称为 virtual host 或 vanity host name) MUST 使用以下规则确定 HTTP/1.1 request 所请求的 resource:

  1. 如果 Request-URI 是 absoluteURI, host 是 Request-URI 的一部分. request 中的任何 Host header field value MUST 被忽略.

  2. 如果 Request-URI 不是 absoluteURI, 且 request 包含 Host header field, 则 host 由 Host header field value 确定.

  3. 如果按规则 1 或 2 确定的 host 不是 server 上的有效 host, response MUST 是 400 (Bad Request) error message.

收到缺少 Host header field 的 HTTP/1.0 request 的 recipient MAY 尝试使用启发式方法 (例如检查 URI path 中是否有某个特定 host 独有的内容), 以确定正在请求的确切 resource.

5.3 Request Header Field

request-header field 允许 client 向 server 传递关于 request 以及 client 自身的额外信息. 这些字段充当 request modifier, 其语义等价于编程语言 method invocation 上的参数.

   request-header = Accept                   ; Section 14.1
                  | Accept-Charset           ; Section 14.2
                  | Accept-Encoding          ; Section 14.3
                  | Accept-Language          ; Section 14.4
                  | Authorization            ; Section 14.8
                  | Expect                   ; Section 14.20
                  | From                     ; Section 14.22
                  | Host                     ; Section 14.23
                  | If-Match                 ; Section 14.24

                  | If-Modified-Since        ; Section 14.25
                  | If-None-Match            ; Section 14.26
                  | If-Range                 ; Section 14.27
                  | If-Unmodified-Since      ; Section 14.28
                  | Max-Forwards             ; Section 14.31
                  | Proxy-Authorization      ; Section 14.34
                  | Range                    ; Section 14.35
                  | Referer                  ; Section 14.36
                  | TE                       ; Section 14.39
                  | User-Agent               ; Section 14.43

request-header field name 只有结合协议版本变化才能可靠扩展. 但是, 如果通信各方都认识到新的或实验性 header field 是 request-header field, 则 MAY 赋予它们 request-header field 的语义. 未识别的 header field 被当作 entity-header field 处理.

最后于 更新