发现对于HTTP协议不能脱口而出，故而怒翻资料，RFC2616 。
在其abstract中是这么说HTTP的，应用层协议，generic、无状态。其特点之一是 the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
Messages以一种类似Internet mail使用的格式来传输，由MIME（Multipurpose Internet Mail Extensions）定义。
术语
connection：在两个程序之间因通信目的而创建的传输层虚拟回路。
message：HTTP通信的基本单元，由符合语法的结构化的八位组（octets）序列组成，通过connection传输。
request：一个HTTP request message。
response：一个HTTP response message。
resource：一个网络数据对象或者服务，可由URI确定。resources可能以multiple representations呈现（如多种语言、多种格式、多种尺寸等）。
entity：request或response承载传输的信息。一个entity由元数据（entity-header fields形式）和内容（entity-body）组成。
representation：response中的entity，服从于content negotiation。一个特别的response status可能存在multiple representations。
content negotiation：当服务一个request时，挑选合适的representation的机制。任何response的entity的representation都可被negotiated（包括error responses）。
variant：任意时刻，一个resource可能关联到一个或多个representation(s)。每一个representation就是一个variant。variant术语的使用，不意味着resource服从于content negotiation。
client：一个program，其创建connections的目的是发送requests。
user agent：发起request的client。通常是浏览器、编辑器、spiders（爬虫），或其他终端用户工具。
server：一个application program，接受connections以服务requests，会发回responses。任何program都可能既是client也是server。
origin server：一个server，具备指定的resource，或者将要创建该resource。
proxy：中间级program，同时扮演server和client角色，以代表其他clients发起requests。一个”transparent proxy”是说除了必要的proxy认证和识别之外，不会修改request或response的proxy。一个”non-transparent proxy”则会修改request或response，以为user agent提供一些额外的服务，例如group annotation services, media type transformation, protocol reduction, or anonymity filtering。
gateway：一个server，但为一些server扮演中间级。不像proxy，一个gateway接收requests就像它是requested resource的原始server一样；发起request的client不会意识到它是同一个gateway通信。
tunnel：一个中间级program，扮演了两个connections之间的盲人中继。一旦被激活，tunnel就不被认为是HTTP通信的一部分，虽然该tunnel可能是由一个HTTP request引起的！当被中继的connections的两端都关闭时，该tunnel就消失了。 -- 和gateway什么区别？
cache：program对response messages的local sotre，以及控制其message storage、retrieval、还有deletion的subsystem。一个cache会存储可缓存的responses，以便将来减少response时间和网络带宽的消耗。任何client或server都可以有一个cache，但扮演tunnel的server不能使用cache。
cacheable：只有在允许缓存存储response message的副本以用于回答后续requests时，该response才是cacheable的。就算一个resource是cacheable的，也可能有更多的限制来决定一个cache是否能够针对一个特别的request使用缓存过的副本。
first-hand：如果response直接来自origin server，没有不必要的延迟，例如经过一个或多个proxies，那该response就是first-hand。如果response的validity是由origin server直接检查的，那该response也是first-hand。 -- 没搞明白，经过proxy到底是不是first-hand？？？
explicit expiration time：origin server决定cache不应返回一个entity的时间？？ The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.
heuristic expiration time：当explicit expiration time不可用时，cache指定的expiration time。
age：一个response的age是指自origin server发送或成功校验时起的时间。
freshness lifetime：从response的生成到它的expiration time之间的时间长度。
fresh：如果response的age没有超出其freshness lifetime，那该response就是fresh的。
stale：如果response的age已经超出了其freshness lifetime，那该response就是stale。
semantically transparent：当一个cache是semantically transparent时，client会接收到与origin server直接处理返回的内容完全一样的内容 -- 除了hop-by hop headers。就是说，当cache的使用不会影响client和origin server -- 除了提高性能时，该cache相对某个response来说，就是semantically transparent。
validator：一个协议的元素（例如，一个entity tag，或一个Last-Modified time），用于找出一个cache entry是否是一个entity的等效副本。
upstream/downstream：描述了一个message的flow。所有的messages flow都是从upstream到downstream。
inbound/outbound：是指messages的request and response paths。inbound意味着向着origin server旅行；outbound意味着向着user agent 旅行。
HTTP通信通常基于TCP/IP连接。默认端口是TCP 80，但也可以使用别的端口。
在HTTP/1.0时代，多数HTTP实现为每次request/response exchange都使用一个新的connection。在HTTP/1.1时代，一个connection可能被用于一个或多个request/response exchanges，虽然connections可能由于种种原因被关闭。
URI 曾经有多种名字，但HTTP关心的只有Uniform Resource Identifiers，是简单格式化的字符串，能够区别出一个resource，通过名字、位置或其他特性。
http scheme，用于通过HTTP协议定位网络资源。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
默认80端口。如果一个proxy接收了一个不是全限定域名的host name，它可能将其自身的域名添加到该host name。如果一个proxy接收了全限定域名，proxy必须不准修改host name。
URI对比：
- 如果没指定端口，或端口空着，等效于默认端口（80）。
- host name的对比必须大小写不敏感。
- scheme names的对比必须大小写不敏感。
- 空的abs_path，等效于abs_path为”/”。
另外，在保留字和不安全字的集合（见RFC 2396）之外的字符，等效于他们的%HEX HEX编码。
例如，下面这些URIs是等效的：
http://abc.com:80/~smith/home.html
Date/Time 格式
HTTP应用历史上允许三种不同格式的date/time stamps representation：
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
第一种格式推荐作为Internet标准；第二种格式很常用。HTTP/1.1 clients 和 servers必须同时能够接受这三种格式。
所有的HTTP date/time stamps必须用GMT时间。用于HTTP时，GMT完全等于UTC。
HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"注意：HTTP对date/time stamp的要求仅限于协议内部使用。client 和 server不要求使用这些格式为用户呈现。
字符集 Character Sets
HTTP使用了MIME对Character Set的定义。注意，这种Character Set也被叫做 Character Encoding。应用应该使用IANA registry中的字符集。
一些HTTP/1.0软件，已经将Content-Type header解释