电影av在线,日韩久久在线,亚洲一区在线观看视频

http(大纲)<7>

英雄 — Fri, 07 Oct 2005 09:49:00 GMT

摘要: 13 Caching in HTTP HTTP多应用于分布式信息系�l�，通过使用response�~�存来提高性能。HTTP/1.1包括许多元素来�ɾ~�存发挥作用成�ؓ可能�?Cache的目的和机制概述�?关于降低语义透明度�?13.1.1 Cache Correctness �q�回最新response�Q�满��的条�g 如果无法做到�Q�那么应该返回error,war... 阅读全文

英雄 2005-10-07 17:49 发表评论

HTTP<6>

英雄 — Tue, 27 Sep 2005 14:24:00 GMT

摘要: 9 �Ҏ��定义 HTTP/1.1通用�Ҏ��的定义如下。虽然这个集合可以被扩展�Q�但是�ƈ不能保证client和server拥有�Ҏ��展的相同定义�?HOST request-header头区必须存在于所有的HTTP/1�?request�?9�Q? 安全和等�q�方�?9.1.1 安全�Ҏ�� 实现者要意识到��Y件代表了用户在Internet上的操作�Q�应该认真地让用��L��道他们可以采取的action会给他们自己... 阅读全文

英雄 2005-09-27 22:24 发表评论

HTTP协议<5>

英雄 — Fri, 23 Sep 2005 03:51:00 GMT

摘要: 5 ��h�� 一个从client到server的request�Q�在�W�一行，包含应用于资源的�Ҏ��Q�资源标志，和��用的协议版本�?Request = Request-Line ; Section 5.1 *(( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) CRLF) ; Section... 阅读全文

英雄 2005-09-23 11:51 发表评论

HTTP1.1��译<4>

英雄 — Wed, 21 Sep 2005 13:21:00 GMT

摘要: 4.HTTP 消息 4�Q?消息�c�d�� HTTP消息由客��L��发到服务器端的request和相反方向的response�l�成�?HTTP-message = Request | Response ; HTTP/1.1 messages Request(sec5)和response(sec6)消息使用RFC822[9]的通用消息格式来传递实体（message的有效负��P��。由一个开始行�Q?或多个头区（... 阅读全文

英雄 2005-09-21 21:21 发表评论

HTTP/1.1协议中文��译<3>

英雄 — Tue, 20 Sep 2005 12:53:00 GMT

摘要: 3协议参数 3�Q?HTTP版本 HTTP使用一个�?lt;major>.”模式来标志协议版本。协议版本就是要允许发送者表达message格式的信息以及它理解更多HTTP协议的能力（不只是说通讯的功能）。加了不影响通讯行�ؓ的MESSAGE�l��g或加了扩展的域值都不必改变版本受��?lt;minor>增大表示协议被改变，一般的MESSAGE解析��法没有变，但是增加... 阅读全文

英雄 2005-09-20 20:53 发表评论

英雄 — Fri, 16 Sep 2005 06:51:00 GMT

2�Q?基本规则

下面�q�些规则描述了基本的解析�W�号�Q�诏�I�于整篇规范中�?SPAN lang=EN-US>US-ASCII字符集在ANSI X3.4-1986[21]中被定义�?o:p>

OCTET =

CHAR =

UPALPHA =

LOALPHA =

ALPHA = UPALPHA | LOALPHA

DIGIT =

CTL =

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

CR =

LF =

SP =

HT =

<"> =

HTTP/1�? 定义了回车换行作为所有协议元素行�l�束标志�Q�entity-body除外。在entity-body的行�l�束标志和它相关联的数据�c�d��紧密联系�Q�des3.7�?o:p>

CRLF = CR LF

HTTP/1�?头区的值可以多行，但需要接�l�行以一个空格或水��^TAB开头。所有的LWS�Q�可以�{弯，都和SP有相同的语义。一�?可以在解释域值和转向message downstream时代替�Q何的LWS用一个单独的SP�?o:p>

LWS =[CRLF]1*�Q�SP|HT�Q?o:p>

TEXT只被用来描述那些不会被message 解析器解析的域内容域倹{��只要按RFC2047[14]�~�码�Ӟ��*TEXT可以包含除ISO-8859-1[22]在外的所有字�W��?o:p>

TEXT =

一�?SPAN lang=EN-US>CRLF在TEXT定义中只作�ؓ头区的��l�的一部分。多行的LWS会在其所在TEXT被解释前被一个单独的SP取代�?o:p>

十六�q�制数字字符在几个协议元素中被��用�?SPAN lang=EN-US>

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

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

许多HTTP/1�?头区值由LWS或一些特�D�字�W�分隔的字符�l�成。而在参数��|��des3.6�Q�中�q�些�Ҏ��的字�W�必��d��一对引号中被��用�?o:p>

token = 1*

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

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

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

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

注释可以包含在一�?SPAN lang=EN-US>HTTP头区内，但是要在�Q�）内。而且只能在注释区内。在其他区，会被认�ؓ是区值的一部分�?o:p>

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

ctext =

一�?SPAN lang=EN-US>text字符串如果被双引号包着�Q�那会被认�ؓ是一个单独的词�?o:p>

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

qdtext = >

斜划�U�可以被作�ؓ单字�W�的转换机制�Q�但是必��要在引号内包着�Q��ƈ且是在注释区�?SPAN lang=EN-US>

quoted-pair = "\" CHAR

英雄 2005-09-16 14:51 发表评论

英雄 — Fri, 16 Sep 2005 01:02:00 GMT

1 引言�Q?005-9-16�Q?BR>1�Q?目的

HTTP是一个�ؓ分布式的协作的超媒体的信息系�l�而徏立的应用层上的协议。自�?990�q�就被www采用。第一个版本，HTTP/0�?�Q�是一个简单的跨INTERNET传输原始数据的协议。HTTP/1.0�Q�在RFC1945[6]描述�Q�，允许信息以类似MIME形式存在�Q�包含关于传输数据的描述元数据和一些关于REQUEST/RESPONSE语义描述�W?/FONT>�Q?SPAN style="COLOR: black">。但是，HTTP/1�?�q�没有考虑到多�U�代理，�~�存�Q�持久连接的需要，或着虚拟��L��。另外，��来��多的HTTP/1�?的不兼容实现也��得一个新版本的出现变的必要（需要一个统一版本来��协议双方��定彼此实现了哪些功能）�?o:p>

�q�䆾规范定义�?SPAN lang=EN-US>HTTP/1�?协议。这份协议比HTTP/1�?包含了更严格的限�Ӟ��以此来保证实现的可靠性，兼容性�?o:p>

实际的信息系�l�要求更多功能而不仅仅是简单的取数据，��包括查询，前台更新�Q�注解�?SPAN lang=EN-US>HTTP允许一个开攄��Ҏ��和头的集合来表示REQUEST的确切要求（对基于URI,URL,URN指定的资源的要求�Q�。而传递的信息则采用类似MIME信息格式�?o:p>

HTTP也被用来做客��L��和处理其他信息系�l�（SMTP�Q�NNTP�Q�FTP�Q�GOPHTER�Q�WAIS�Q�。的代理/�|�关的交��。这��P��HTTP允许各种各样的应用访问基本的多媒体资源�?o:p>

1. 2要求

在这个文档里出现的关键词“MUST�? “MUST NOT�? “REQUIRED�? “SHALL�? “SHALL NOT�? “SHOULD�? “SHOULD NOT�? “RECOMMENDED�? “MAY�? and “OPTIONAL”按RFC2119[34]描述的那栯��释�?o:p>

如果�?SPAN lang=EN-US>1个或多个MUST�Q�REQUIRED水��^的要求未满��Q�那么这个实现就是不兼容的。如果满��x��有的MUST�Q�REQUIRED�Q�SHOULD水��^的要求，那么�q�个实现��“unconditionallycompliant�?

满��所�?SPAN lang=EN-US>MUST但是不是所有SHOULD是“conditionally compliant”�?o:p>

1�Q?术语

�q�个规范用了许多术语来描�q�在HTTP交流中的参与者和对象�?o:p>

Connection

�?SPAN lang=EN-US>2个要交流的程序间建立的虚拟传输层信�\�?o:p>

Message

基本�?SPAN lang=EN-US>HTTP交流单元。由�l�构化的字节��构成，其结构符合SECTION4的词法定义；通过CONNECTION传递�?o:p>

Request

一�?SPAN lang=EN-US>HTTP request message�Q�SECTION 5 DES�?o:p>

Response

一�?SPAN lang=EN-US>HTTP response message�Q�SECTION 6 DES�?o:p>

Resource

一个能够被URI标识的网�l�数据对象或服务�Q�SECTION3�? DES。资源可以有多种表示�Q��ƈ且可以在其他斚w��有所变化�?o:p>

Entity

被一�?SPAN lang=EN-US>request或response作�ؓ有效负荷传输的信息。由头区的元数据信息和体区的数据区组成，SECTION7 des�?o:p>

Representation

在一�?SPAN lang=EN-US>response里的属于content negotiation的entity�Q�SECTION12 des。在1个response中可以存在多个representation�?o:p>

Content negotiation

一�U�机�Ӟ��用来选择合适的representation来服务一个request�Q�SECTION12 des�?o:p>

Variant

一个资源可以在��M��l�定时刻拥有多个representation。每一个被命名为variant�?o:p>

Client

一个用来徏立连接发�?SPAN lang=EN-US>request的程序�?o:p>

User agent

发送一�?SPAN lang=EN-US>request的client。最常见的是��览�?o:p>

Server

接受�q�接用来�?SPAN lang=EN-US>request服务�q�且发送回response的应用程序。�Q何一个程序都可以既做server�Q�又做client,�q�里的概忉|��的就是在一�ơconnection中的角色�Q�而不是一般意义下的程序的能力。同��P��M��server可以作�ؓ一个origin server�Q�proxy,gateway,或者tunnel�Q�基于请求的性质做出不同的行为�?o:p>

Orgin server

一个指定的资源的所在地或被创徏地的server�?o:p>

Proxy

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

Gateway

一个用来�ؓ其他server服务的server。不象一个proxy�Q�一个gateway接受��h��好象他是请求resource的origin server一��P��而请求client可能�Ҏ��׃��知道�l�过了一个gateway�?o:p>

Tunnel

一个中间程序，在两�?SPAN lang=EN-US>conncetion之间做一个透明传递。一旦激�z�，它将不被认�ؓ是HTTP交流的一部分�Q�虽然它可能是被HTTP��h��初始化的。当两个connection都关闭后它也消失了�?o:p>

Cache

�E�序�?SPAN lang=EN-US>reponse message的局部存储，包括控制�Q�查询，删除存储的子�pȝ��。一个cache存储cache response用来应对未来的同��L��h��Q�达到降低reponse旉��和带宽消耗的目的。�Q何client和server都可以包括一个cache�Q�但是一个cache不能被一个tunnel使用�?o:p>

Cacheable

如果一�?SPAN lang=EN-US>cache可以存储response message的备份来应对以后的请求，那么�q�个response��是cacheable。SECTION13 des。即使一个response是Cacheable�Q�也有另外的限制来决定是否一个cache可以用一个cache拯��来应对请求�?o:p>

First-hand

一�?SPAN lang=EN-US>response是从origin server或经�q�了几个proxy�q�来的那么就是first-hand。如果它的有效性被origin server校验�q�那它也是first-hand�?o:p>

Explicit expiration time

Origin server��定的关于一个entity不应再由一个cache未经�q�一步校验就�q�回的时间�?o:p>

Herristic expiration time

如果一�?SPAN lang=EN-US>Explicit expiration time不可用，那么�q�个旉��被缓存��?o:p>

age

一�?SPAN lang=EN-US>response的age是自从它被发送或成功地被origin server校验后的旉��D?o:p>

freshness lifetime

一�?SPAN lang=EN-US>response自从产生到expiration time之间的时间长�?o:p>

fresh

一�?SPAN lang=EN-US>response是fresh的，如果它的age�q�没有超�q�它的freshness lifetime�?o:p>

Stale

一�?SPAN lang=EN-US>response是stale的，如果它的age��过了它的freshness lifetime�?o:p>

Semantically transparent

一�?SPAN lang=EN-US>cache一一�U�Semantically transparent的方式工作，对于特定的一个response�Q�这时它的��用既没有影响request client也没有媄响origin server�Q�和没经�q�cache一��P��Q�但是却提高了性能�?o:p>

Validator

一个协议元素被用来扑և�一�?SPAN lang=EN-US>cache entity 是不是等同于一个entity�?o:p>

Upstream/downstream

描述了一�?SPAN lang=EN-US>message的流动：所有的message从upstream��向downstream�?o:p>

Inbound/outbound

是指message的request和response路径。前者只��向origin server�Q�后者指��向user agent�?o:p>

1.4整体�q�行框架

HTTP协议是一个request/response协议。一个client发送一个request�l�一个server�Q�由一个request method,uri,协议版本�Q�紧跟着mime�c�M��的信息（包含request描述�W�，client的信息，和与一个server传递数据可能的定w��Q�。Server回以一个状态行�Q�包括message的协议版本，一个成功或��p�|的代码）�Q�紧跟一个MIME�c�M��的message�Q�包括server信息�Q�entity的元数据�Q�可能的entity-body定w��。HTTP和MIME的关�p�appendix19.4�?o:p>

大多数的HTTP�q�接被一个user agent发�v�Q�请求某些origin server上的资源。在��单情况，可以如图所�C�：

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

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

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

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

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

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

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

上面的图展示�?SPAN lang=EN-US>3个中间体abc在user agent和origin server之间。一个request或response message�I�越整个��N��要通过4个独立的�q�接。这个区别是很重要的�Q�因��Z��?HTTP通讯选项只能加到最�q�的�Q�非tunnel��d��Q�只能到chain的末端或所有连接。虽然图是画地直�U�，但是每一个参与者可能同时处理多个通讯。比如，B在处理A的request 的同时可能正在接受其他clients发过来的request�Q�而把它们转向非c的server�?o:p>

��M��参与通讯的只要不�?SPAN lang=EN-US>tunnel都可以用一个内部cache来处理request。这会羃短通讯铑֦�果有一�Ҏ��对该request的cached reponse。下面展�C�Z��l�果铑֦�果B有一个从O的cache copy�Q�而UA�Q�或A没有�?o:p>

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

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

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

�q�不是所有的response的缓存都是有用的�Q�一些request可能会包含关于缓存要求的描述�W�。HTTP对于�~�存的方式控制和response�Q�des13�?o:p>

事实上，�~�存和代理的构架现在正在被整�?SPAN lang=EN-US>WWW实验和部�|�Ӏ�这些系�l�包括国家��的代理缓存来存储��洋的带宽，�pȝ��q�播或多�Ҏ��送cached entries�Q�组�l�那些零散的�~�存到CD-ROM�{�等。HTTP�pȝ��也在公司内网的宽带连接和PDA的低能耗无�U�断�l�连接系�l�中被��用。HTTP1�?的目标是支持在协议诞生期间已�l�部�|�的各种配置�Q��得WEB应用能够辑ֈ�高可靠性，臛_��是在��p�|后有可靠的提�C��?o:p>

HTTP通讯通常是跨TCP/IP�q�接地发生。默认端口是TCP80[19]�Q�但是其他的端口也可以被使用。这��׃��HTTP可以作�ؓINTERNET上其他协议的上层协议�Q�或其他�|�络的协议。HTTP只要求一个可靠连接，��M��能提供这��L��保证的协议都可以被��用；把HTTP/1�?的request和response的结构�{化成正在被讨论的协议的数据单位超��Z��本规范的范围�?o:p>

�?SPAN lang=EN-US>HTTP/1�?�Q�大多数实现使用一个新的连接应对request/response交换。在HTTP/1�?中，一个连接可以被多个request/response交流使用�Q�虽然连接可以因为多个原因被关闭�?o:p>

英雄 2005-09-16 09:02 发表评论