- 浏览: 2649573 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
80后的童年2:
深入浅出MongoDB应用实战开发网盘地址:https://p ...
MongoDB入门教程 -
shliujing:
楼主在不是精通java和php的前提下,请不要妄下结论。
PHP、CakePHP哪凉快哪呆着去 -
安静听歌:
希望可以一给一点点注释
MySQL存储过程之代码块、条件控制、迭代 -
qq287767957:
PHP是全宇宙最强的语言!
PHP、CakePHP哪凉快哪呆着去 -
rryymmoK:
深入浅出MongoDB应用实战开发百度网盘下载:链接:http ...
MongoDB入门教程
http://www.w3.org/Protocols/rfc2616/rfc2616.html
http://en.wikipedia.org/wiki/Backus-Naur_form
http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
Terminology
connection
A transport layer virtual circuit established between two programs for the purpose of communication.
message
The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in section 4 and transmitted via the connection.
request
An HTTP request message, as defined in section 5.
response
An HTTP response message, as defined in section 6.
resource
A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.
entity
The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in section 7.
representation
An entity included with a response that is subject to content negotiation, as described in section 12. There may exist multiple representations associated with a particular response status.
content negotiation
The mechanism for selecting the appropriate representation when servicing a request, as described in section 12. The representation of entities in any response can be negotiated (including error responses).
variant
A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
client
A program that establishes connections for the purpose of sending requests.
user agent
The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
server
An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
origin server
The server on which a given resource resides or is to be created.
proxy
An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
gateway
A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.
tunnel
An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed.
cache
A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
cacheable
A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
first-hand
A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more proxies. A response is also first-hand if its validity has just been checked directly with the origin server.
explicit expiration time
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
An expiration time assigned by a cache when no explicit expiration time is available.
age
The age of a response is the time since it was sent by, or successfully validated with, the origin server.
freshness lifetime
The length of time between the generation of a response and its expiration time.
fresh
A response is fresh if its age has not yet exceeded its freshness lifetime.
stale
A response is stale if its age has passed its freshness lifetime.
semantically transparent
A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been handled directly by the origin server.
validator
A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent copy of an entity.
upstream/downstream
Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.
inbound/outbound
Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent"
ABNF
name = definition
The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
"literal"
Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
rule1 | rule2
Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".
*rule
The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
[rule]
Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
N rule
Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
#rule
A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as
( *LWS element *( *LWS "," *LWS element ))
can be shown as
1#element
Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
; comment
A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
implied *LWS
The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or
separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
ABNF Basic Rules
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)>
CRLF = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs,
but including LWS>
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
http://en.wikipedia.org/wiki/Backus-Naur_form
http://en.wikipedia.org/wiki/Augmented_Backus%E2%80%93Naur_Form
Terminology
connection
A transport layer virtual circuit established between two programs for the purpose of communication.
message
The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in section 4 and transmitted via the connection.
request
An HTTP request message, as defined in section 5.
response
An HTTP response message, as defined in section 6.
resource
A network data object or service that can be identified by a URI, as defined in section 3.2. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.
entity
The information transferred as the payload of a request or response. An entity consists of metainformation in the form of entity-header fields and content in the form of an entity-body, as described in section 7.
representation
An entity included with a response that is subject to content negotiation, as described in section 12. There may exist multiple representations associated with a particular response status.
content negotiation
The mechanism for selecting the appropriate representation when servicing a request, as described in section 12. The representation of entities in any response can be negotiated (including error responses).
variant
A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
client
A program that establishes connections for the purpose of sending requests.
user agent
The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
server
An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
origin server
The server on which a given resource resides or is to be created.
proxy
An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
gateway
A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.
tunnel
An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist when both ends of the relayed connections are closed.
cache
A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
cacheable
A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
first-hand
A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more proxies. A response is also first-hand if its validity has just been checked directly with the origin server.
explicit expiration time
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
An expiration time assigned by a cache when no explicit expiration time is available.
age
The age of a response is the time since it was sent by, or successfully validated with, the origin server.
freshness lifetime
The length of time between the generation of a response and its expiration time.
fresh
A response is fresh if its age has not yet exceeded its freshness lifetime.
stale
A response is stale if its age has passed its freshness lifetime.
semantically transparent
A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been handled directly by the origin server.
validator
A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent copy of an entity.
upstream/downstream
Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.
inbound/outbound
Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent"
ABNF
name = definition
The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
"literal"
Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
rule1 | rule2
Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".
*rule
The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
[rule]
Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
N rule
Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
#rule
A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and OPTIONAL linear white space (LWS). This makes the usual form of lists very easy; a rule such as
( *LWS element *( *LWS "," *LWS element ))
can be shown as
1#element
Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element MUST be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
; comment
A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
implied *LWS
The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or
separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
ABNF Basic Rules
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)>
CRLF = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs,
but including LWS>
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
发表评论
-
leveldb资料整理
2011-12-28 19:50 10670leveldb介绍 http://code.google.co ... -
HTTP Basic/Digest Authentication、OAuth
2009-01-09 14:01 9571HTTP Authentication au ... -
HTTP1.1 Notes 8, Header Field Definitions
2008-12-31 13:13 4420http://www.w3.org/Protocols/rfc ... -
HTTP1.1 Notes 7, Status Code Definitions
2008-12-30 15:01 3270Informational 1xx This class of ... -
HTTP1.1 Notes 6, Method Definitions
2008-12-30 12:30 2462Safe and Idempotent Methods In ... -
HTTP1.1 Notes 5, Connections
2008-12-29 13:25 2693Persistent Connections advantag ... -
HTTP1.1 Notes 4, Request & Response & Entity
2008-12-26 13:25 4149Request Request = ... -
HTTP1.1 Notes 3, HTTP Message
2008-12-26 10:57 4167Message Types HTTP-mess ... -
HTTP1.1 Notes 2, Protocol Parameters
2008-12-24 13:12 2677HTTP Version HTTP-Versio ... -
以后都用MindManager做年度总结和年度计划
2008-12-19 19:54 59842008总结如下: 2009计划如下: 希望自己能够戒骄 ... -
Skip List 跳表
2008-12-19 15:54 5523跳表是个概率性的的数据结构,由William Pugh在199 ... -
数据仓库toolkit笔记1,Dimensional Modeling Primer
2008-12-15 18:49 2383数据仓库管理员的主要职责: 1,通过业务领域、工作职责和计算机 ... -
CLRS笔记15,动态规划
2008-12-10 18:14 1849动态规划算法的实质是分治思想和解决冗余,因此,动态规划是一种将 ... -
Web搜索引擎原理和技术
2008-12-08 12:06 4804主要的三个功能模块: ... -
CLRS笔记12,二叉查找树/红黑树
2008-12-04 17:32 2795二叉查找树 二叉查找树是一颗二叉树,并且每个节点x的左子树中所 ... -
CLRS笔记11,Hash Table
2008-12-03 15:02 1978Hash Table是实现动态集合在O(1)时间内的INSER ... -
CLRS笔记10、基本数据结构
2008-11-28 14:28 1881数学中的集合是不变的 ... -
CLRS笔记8,线性时间排序(counting、radix、bucket sort)
2008-11-27 11:13 3457线性时间排序即时间复杂度为Θ(n)的排序,主要有计数排序、基数 ... -
How to be Computer Game Developer?
2008-07-21 13:35 1240http://www.beyondrails.com/blog ... -
游戏引擎剖析
2008-07-21 11:59 2368转载一篇《游戏引擎剖析》系列,了解游戏引擎开发相关的知识。 ...
相关推荐
Batch Control Part 1 Models and Terminology
BS EN 764-1-2004 Part 1 Terminology — Pressuretemperature volume
This standard provides standard models and terminology for describing the interfaces between the business systems of an entreprise and its manufacturing-control systems. The models and terminology ...
Part 1: Terminology and common tests (ISO 5395-1:2013) This British Standard is the UK implementation of EN ISO 5395-1:2013. Together with BS EN ISO 5395-2:2013 and BS EN ISO 5395-3:2013 it supersedes...
You must learn the material, know the terminology and techniques, understand the concepts, and be able to answer 100 multiple-choice questions quickly and (at least 70%) correctly. A good estimate of...
SAE J670e-1976 Vehicle Dynamics Terminology.pdf
Fun, quick, and easy to study while on the go, Mosby’s Medical Terminology Flash Cards, 3rd Edition provide a great tool for learning and reviewing medical terms. 600 full-color flash cards help ...
SAE J1715_2:2013 Battery Terminology - 完整英文版(15页).zip
c++11 Value Terminology
ISA-88.00.01-1995-XXXX_BatchControl_Part 1 Models and Terminology.pdf
IEEE_standard_for_Terminology_and_Test_methods_for_ADC_Std_1241-2010
为CPIM认证考试准备。各类定义参考。 全英文。 有使用过的,认为很有用。
一本介绍GSM非常好的书,适合初入门和有经验的专业人士
1. 下载压缩文件并解压缩,得到Terminology.dictionary文件 2. 将Terminology.dictionary复制到隐藏目录~/Library/Dictionaries中 3. 打开Mac词典程序,从首选项中激活Terminology词典 4. 接下来就可以愉快的查询...
1.1 Terminology / 1 1.1.1 Systems Concepts / 2 1.1.2 Real-Time Definitions / 4 1.1.3 Events and Determinism / 7 1.1.4 CPU Utilization / 10 1.2 Real-Time System Design Issues / 12 1.3 Example Real-Time...
海洋学综合术语 Oceanography general terminology 国家标准 GB/T 15918—1995
SybaseIQ_Architecture and Terminology IQ15
Encyclopedia of Terminology for Educational Communications and Technology, Spring 2013
工控网络与系统信息安全标准综述 IEC 62443-1-1 电子版 全英文 Part 1-1: Terminology, concepts and models
This document contains technical definitions for terms used in the workflow management... The definitions themselves will help in establishing a consistency in the use of terminology across the industry.