下面这些规则描述了基本的解析符号，贯穿于整篇规范中。US-ASCII字符集在ANSI X3.4-1986[21]中被定义。

OCTET = <any 8-bit sequence of data>

CHAR = <any US-ASCII character (octets 0 - 127)>

UPALPHA = <any US-ASCII uppercase letter "A".."Z">

LOALPHA = <any US-ASCII lowercase letter "a".."z">

ALPHA = UPALPHA | LOALPHA

DIGIT = <any US-ASCII digit "0".."9">

CTL = <any US-ASCII control character

(octets 0 - 31) and DEL (127)>

CR = <US-ASCII CR, carriage return (13)>

LF = <US-ASCII LF, linefeed (10)>

SP = <US-ASCII SP, space (32)>

HT = <US-ASCII HT, horizontal-tab (9)>

<"> = <US-ASCII double-quote mark (34)>

HTTP/1。1 定义了回车换行作为所有协议元素行结束标志，entity-body除外。在entity-body的行结束标志和它相关联的数据类型紧密联系，des3.7。

CRLF = CR LF

HTTP/1。1头区的值可以多行，但需要接续行以一个空格或水平TAB开头。所有的LWS，可以转弯，都和SP有相同的语义。一个*可以在解释域值和转向message downstream时代替任何的LWS用一个单独的SP。

LWS =[CRLF]1*（SP|HT）

TEXT只被用来描述那些不会被message 解析器解析的域内容域值。只要按RFC2047[14]编码时，*TEXT可以包含除ISO-8859-1[22]在外的所有字符。

TEXT = <any OCTET except CTLs,but including LWS>

一个CRLF在TEXT定义中只作为头区的继续的一部分。多行的LWS会在其所在TEXT被解释前被一个单独的SP取代。

十六进制数字字符在几个协议元素中被使用。

HEX = "A" | "B" | "C" | "D" | "E" | "F"

| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT

许多HTTP/1。1头区值由LWS或一些特殊字符分隔的字符组成。而在参数值（des3.6）中这些特殊的字符必须在一对引号中被使用。

token = 1*<any CHAR except CTLs or separators>

separators = "(" | ")" | "<" | ">" | "@"

| "," | ";" | ":" | "\" | <">

| "/" | "[" | "]" | "?" | "="

| "{" | "}" | SP | HT

注释可以包含在一些HTTP头区内，但是要在（）内。而且只能在注释区内。在其他区，会被认为是区值的一部分。

comment = "(" *( ctext | quoted-pair | comment ) ")"

ctext = <any TEXT excluding "(" and ")">

一个text字符串如果被双引号包着，那会被认为是一个单独的词。

quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )

qdtext = <any TEXT except <">>

斜划线可以被作为单字符的转换机制，但是必须要在引号内包着，并且是在注释区。

quoted-pair = "\" CHAR

HTTP是一个为分布式的协作的超媒体的信息系统而建立的应用层上的协议。自从1990年就被www采用。第一个版本，HTTP/0。9，是一个简单的跨INTERNET传输原始数据的协议。HTTP/1.0（在RFC1945[6]描述），允许信息以类似MIME形式存在（包含关于传输数据的描述元数据和一些关于REQUEST/RESPONSE语义描述符）。但是，HTTP/1。0并没有考虑到多级代理，缓存，持久连接的需要，或着虚拟主机。另外，越来越多的HTTP/1。0的不兼容实现也使得一个新版本的出现变的必要（需要一个统一版本来使协议双方确定彼此实现了哪些功能）。

这份规范定义了HTTP/1。1协议。这份协议比HTTP/1。0包含了更严格的限制，以此来保证实现的可靠性，兼容性。

实际的信息系统要求更多功能而不仅仅是简单的取数据，将包括查询，前台更新，注解。HTTP允许一个开放的方法和头的集合来表示REQUEST的确切要求（对基于URI,URL,URN指定的资源的要求）。而传递的信息则采用类似MIME信息格式。

HTTP也被用来做客户端和处理其他信息系统（SMTP，NNTP，FTP，GOPHTER，WAIS）。的代理/网关的交流。这样，HTTP允许各种各样的应用访问基本的多媒体资源。

1.  2要求

在这个文档里出现的关键词“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”按RFC2119[34]描述的那样解释。

如果有1个或多个MUST，REQUIRED水平的要求未满足，那么这个实现就是不兼容的。如果满足所有的MUST，REQUIRED，SHOULD水平的要求，那么这个实现就“unconditionallycompliant”;

满足所有MUST但是不是所有SHOULD是“conditionally compliant”。

1．3术语

这个规范用了许多术语来描述在HTTP交流中的参与者和对象。

Connection

在2个要交流的程序间建立的虚拟传输层信路。

Message

基本的HTTP交流单元。由结构化的字节流构成，其结构符合SECTION4的词法定义；通过CONNECTION传递。

Request

一个HTTP request message，SECTION 5 DES。

Response

一个HTTP response message，SECTION 6 DES。

Resource

一个能够被URI标识的网络数据对象或服务，SECTION3。2 DES。资源可以有多种表示，并且可以在其他方面有所变化。

Entity

被一个request或response作为有效负荷传输的信息。由头区的元数据信息和体区的数据区组成，SECTION7 des。

Representation

在一个response里的属于content negotiation的entity，SECTION12 des。在1个response中可以存在多个representation。

Content negotiation

一种机制，用来选择合适的representation来服务一个request，SECTION12 des。

Variant

一个资源可以在任何给定时刻拥有多个representation。每一个被命名为variant。

Client

一个用来建立连接发送request的程序。

User agent

发送一个request的client。最常见的是浏览器

Server

接受连接用来为request服务并且发送回response的应用程序。任何一个程序都可以既做server，又做client,这里的概念指的就是在一次connection中的角色，而不是一般意义下的程序的能力。同样，任何server可以作为一个origin server，proxy,gateway,或者tunnel，基于请求的性质做出不同的行为。

Orgin server

一个指定的资源的所在地或被创建地的server。

Proxy

一个中间程序，既做server又做client(做client是为了其他的的clients)。请求被内部服务或者被传递（有可能做下翻译）到其他server。一个proxy必须实现规范关于client和server的双重要求。一个“transparent proxy“是一个不对request和response做超越代理鉴定要求处理的proxy，相反就是做。除了“transparent proxy”或者“non-transparent proxy”被明确指定的特殊行为外，HTTP proxy 的要求也适用于这两种proxy。

Gateway

一个用来为其他server服务的server。不象一个proxy，一个gateway接受请求就好象他是请求resource的origin server一样；而请求client可能根本就不知道经过了一个gateway。

Tunnel

一个中间程序，在两个conncetion之间做一个透明传递。一旦激活，它将不被认为是HTTP交流的一部分，虽然它可能是被HTTP请求初始化的。当两个connection都关闭后它也消失了。

Cache

程序对reponse message的局部存储，包括控制，查询，删除存储的子系统。一个cache存储cache response用来应对未来的同样的请求，达到降低reponse时间和带宽消耗的目的。任何client和server都可以包括一个cache，但是一个cache不能被一个tunnel使用。

Cacheable

如果一个cache可以存储response message的备份来应对以后的请求，那么这个response就是cacheable。SECTION13 des。即使一个response是Cacheable，也有另外的限制来决定是否一个cache可以用一个cache拷贝来应对请求。

First-hand

一个response是从origin server或经过了几个proxy过来的那么就是first-hand。如果它的有效性被origin server校验过那它也是first-hand。

Explicit expiration time

Origin server确定的关于一个entity不应再由一个cache未经进一步校验就返回的时间。

Herristic expiration time

如果一个Explicit expiration time不可用，那么这个时间被缓存使用

age

一个response的age是自从它被发送或成功地被origin server校验后的时间段

freshness lifetime

一个response自从产生到expiration time之间的时间长度

fresh

一个response是fresh的，如果它的age还没有超过它的freshness lifetime。

Stale

一个response是stale的，如果它的age超过了它的freshness lifetime。

Semantically transparent

一个cache一一种Semantically transparent的方式工作，对于特定的一个response，这时它的使用既没有影响request client也没有影响origin server（和没经过cache一样），但是却提高了性能。

Validator

一个协议元素被用来找出一个cache entity 是不是等同于一个entity。

Upstream/downstream

描述了一个message的流动：所有的message从upstream流向downstream。

Inbound/outbound

是指message的request和response路径。前者只流向origin server，后者指流向user agent。

1.4整体运行框架

HTTP协议是一个request/response协议。一个client发送一个request给一个server，由一个request method,uri,协议版本，紧跟着mime类似的信息（包含request描述符，client的信息，和与一个server传递数据可能的容量）。Server回以一个状态行（包括message的协议版本，一个成功或失败的代码），紧跟一个MIME类似的message（包括server信息，entity的元数据，可能的entity-body容量。HTTP和MIME的关系appendix19.4。

大多数的HTTP连接被一个user agent发起，请求某些origin server上的资源。在简单情况，可以如图所示：

request chain ------------------------>

UA -------------------v------------------- O

<----------------------- response chain

一个更加复杂点的情况：有多个中间体介于request/response chain。有3个普遍的中间体形式：proxy，gateway，tunnel。一个proxy是一个转送站，接受一个request,更改全部或部分message，根据uri重新发request。一个gateway是一个接受站，就象居于其他一些server之上的server一样，如果必要，会把requeset传给它下面的server。一个tunnel是一个接力点，连接2个连接而不改变任何message；可以被用来处理防火墙。

request chain -------------------------------------->

UA -----v----- A -----v----- B -----v----- C -----v----- O

<------------------------------------- response chain

上面的图展示了3个中间体abc在user agent和origin server之间。一个request或response message穿越整个链需要通过4个独立的连接。这个区别是很重要的，因为一些 HTTP通讯选项只能加到最近的，非tunnel邻居，只能到chain的末端或所有连接。虽然图是画地直线，但是每一个参与者可能同时处理多个通讯。比如，B在处理A的request 的同时可能正在接受其他clients发过来的request，而把它们转向非c的server。

任何参与通讯的只要不是tunnel都可以用一个内部cache来处理request。这会缩短通讯链如果有一方有对该request的cached reponse。下面展示了结果链如果B有一个从O的cache copy，而UA，或A没有。

request chain ---------->

UA -----v----- A -----v----- B - - - - - - C - - - - - - O

<--------- response chain

并不是所有的response的缓存都是有用的，一些request可能会包含关于缓存要求的描述符。HTTP对于缓存的方式控制和response，des13。

事实上，缓存和代理的构架现在正在被整个WWW实验和部署。这些系统包括国家级的代理缓存来存储越洋的带宽，系统广播或多点播送cached entries，组织那些零散的缓存到CD-ROM等等。HTTP系统也在公司内网的宽带连接和PDA的低能耗无线断续连接系统中被使用。HTTP1。1的目标是支持在协议诞生期间已经部署的各种配置，使得WEB应用能够达到高可靠性，至少是在失败后有可靠的提示。

HTTP通讯通常是跨TCP/IP连接地发生。默认端口是TCP80[19]，但是其他的端口也可以被使用。这就使HTTP可以作为INTERNET上其他协议的上层协议，或其他网络的协议。HTTP只要求一个可靠连接，任何能提供这样的保证的协议都可以被使用；把HTTP/1。1的request和response的结构转化成正在被讨论的协议的数据单位超出了本规范的范围。

在HTTP/1。0，大多数实现使用一个新的连接应对request/response交换。在HTTP/1。1中，一个连接可以被多个request/response交流使用，虽然连接可以因为多个原因被关闭。