从客户端到服务器的请求消息在该消息的第一行中包括要应用于资源的方法、资源的标识符和使用的协议版本。
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-URI 和协议版本,并以 CRLF 结尾。 元素由 SP 字符分隔。 除了最后的 CRLF 序列外,不允许使用 CR 或 LF。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
5.1.1 Method
Method 指示要在由 Request-URI 标识的资源上执行的方法。该方法区分大小写。
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
资源所允许的方法列表可以在 Allow 头字段中指定(第 14.7 节)。响应的返回代码总是通知客户端当前是否允许在资源上使用某种方法,因为允许的方法集可以动态地改变。如果源服务器知道该方法但不允许用于请求的资源,那么源服务器应该返回状态代码 405(Method Not Allowed);如果该方法不被源服务器识别或不被实现,那么源服务器应该返回状态代码 501(Not Implemented)。所有通用服务器都必须支持 GET 和 HEAD 方法。所有其它方法都是可选的;但是,如果上述方法被实现,它们必须以第 9 节中规定的相同语义来实现。
5.1.2 Request-URI
Request-URI 是一个统一资源标识符(第 3.2 节),用于标识应用该请求的资源。
Request-URI = "*" | absoluteURI | abs_path | authority
Request-URI 的四个选项取决于请求的性质。星号 “*” 意味着该请求并不适用于某个特定的资源,而是适用于服务器本身,只有当使用的方法不一定适用于某个资源时才允许使用。一个例子是:
OPTIONS * HTTP/1.1
当请求被提交给一个代理时,绝对 URI 形式是必须的。代理被要求转发该请求或从一个有效的缓存中提供服务,并返回响应。请注意,代理可能会将请求转发给另一个代理或直接转发给绝对 URI 指定的服务器。为了避免请求循环,代理必须能够识别其所有的服务器名称,包括任何别名、本地变化和数字 IP 地址。一个请求行的例子是:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
为了允许在未来的 HTTP 版本中的所有请求过渡到绝对 URI,所有的 HTTP/1.1 服务器必须接受请求中的绝对 URI 形式,即使 HTTP/1.1 客户端只在向代理的请求中产生它们。
authority 形式只被 CONNECT 方法使用(第 9.9 节)。
最常见的 Request-URI 形式是用于识别源服务器或网关上的资源。在这种情况下,URI 的绝对路径必须作为 Request-URI 被传送(见 3.2.1 节,abs_path),而 URI 的网络位置(authority)必须在 Host 头字段中传送。例如,一个希望直接从源服务器检索上述资源的客户端将创建一个 TCP 连接到主机 “www.w3.org” 的 80 端口,并发送这些行:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
后面是请求的其余部分。注意,绝对路径不能是空的;如果原始URI中没有,必须以 “/“(服务器 root )的形式给出。
Request-URI 以 3.2.1 节中规定的格式传输。如果 Request-URI 使用 “% HEX HEX” 编码 [42],源服务器必须对 Request-URI 进行解码,以便正确解释该请求。服务器应以适当的状态代码响应无效的 Request-URI。
透明代理在将收到的 Request-URI 转发到下一个入站服务器时,不得重写其 “abs_path” 部分,除非如上所述,用 “/“ 替换空 abs_path。
注意:”不重写” 规则可以防止代理在源服务器不适当地将非保留的 URI 字符用于保留目的时改变请求的含义。 实施者应该意识到,一些 HTTP/1.1 以前的代理机构已经知道重写 Request-URI。
5.2 请求的资源标识符
互联网请求所识别的确切资源是通过检查 Request-URI 和 Host 头字段来确定的。
在确定由 HTTP/1.1 请求标识的资源时,不允许资源因请求的主机而不同的源服务器可以忽略主机头字段值。 (但有关 HTTP/1.1 中主机支持的其他要求,请参阅第 19.6.1.1 节。)
根据所请求的主机(有时被称为虚拟主机或虚构主机名)来区分资源的起源服务器必须使用以下规则来确定HTTP/1.1 请求中所请求的资源。
如果 Request-URI 是一个绝对的 URI,那么主机就是 Request-URI 的一部分。请求中的任何 Host 头字段值都必须被忽略。
如果 Request-URI 不是一个绝对的 URI,并且请求包括一个 Host 头字段,那么主机由 Host 头字段的值决定。
如果由规则 1 或 2 确定的主机不是服务器上的有效主机,响应必须是一个 400(Bad Request)错误信息。
缺少 Host 标头字段的 HTTP/1.0 请求的接收者可以尝试使用启发式方法(例如,检查 URI 路径以获取特定主机独有的内容)以确定正在请求的确切资源。
5.3 请求头字段
请求头字段允许客户端向服务器传递有关请求和客户端本身的额外信息。这些字段作为请求修饰符,其语义相当于编程语言方法调用的参数。
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
请求头字段的名称只有在协议版本改变的情况下才能被可靠地扩展。然而,如果通信中的所有各方都认为请求-头字段是请求-头字段,那么新的或试验性的头字段可能被赋予请求头字段的语义。未被识别的头字段被当作实体头字段处理。