分享
 
 
 

http1.1---1

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

Network Working Group R. Fielding

Request for Comments: 2068 UC Irvine

Category: Standards Track J. Gettys

J. Mogul

DEC

H. Frystyk

T. Berners-Lee

MIT/LCS

January 1997

Hypertext Transfer Protocol -- HTTP/1.1

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

The Hypertext Transfer Protocol (HTTP) is an application-level

protocol for distributed, collaborative, hypermedia information

systems. It is a generic, stateless, object-oriented protocol which

can be used for many tasks, such as name servers and distributed

object management systems, through extension of its request methods.

A feature of HTTP is the typing and negotiation of data

representation, allowing systems to be built independently of the

data being transferred.

HTTP has been in use by the World-Wide Web global information

initiative since 1990. This specification defines the protocol

referred to as "HTTP/1.1".

Table of Contents

1 Introduction.............................................7

1.1 Purpose ..............................................7

1.2 Requirements .........................................7

1.3 Terminology ..........................................8

1.4 Overall Operation ...................................11

2 Notational Conventions and Generic Grammar..............13

2.1 Augmented BNF .......................................13

2.2 Basic Rules .........................................15

3 Protocol Parameters.....................................17

3.1 HTTP Version ........................................17

Fielding, et. al. Standards Track [Page 1]

RFC 2068 HTTP/1.1 January 1997

3.2 Uniform Resource Identifiers ........................18

3.2.1 General Syntax ...................................18

3.2.2 http URL .........................................19

3.2.3 URI Comparison ...................................20

3.3 Date/Time Formats ...................................21

3.3.1 Full Date ........................................21

3.3.2 Delta Seconds ....................................22

3.4 Character Sets ......................................22

3.5 Content Codings .....................................23

3.6 Transfer Codings ....................................24

3.7 Media Types .........................................25

3.7.1 Canonicalization and Text Defaults ...............26

3.7.2 Multipart Types ..................................27

3.8 Product Tokens ......................................28

3.9 Quality Values ......................................28

3.10 Language Tags ......................................28

3.11 Entity Tags ........................................29

3.12 Range Units ........................................30

4 HTTP Message............................................30

4.1 Message Types .......................................30

4.2 Message Headers .....................................31

4.3 Message Body ........................................32

4.4 Message Length ......................................32

4.5 General Header Fields ...............................34

5 Request.................................................34

5.1 Request-Line ........................................34

5.1.1 Method ...........................................35

5.1.2 Request-URI ......................................35

5.2 The Resource Identified by a Request ................37

5.3 Request Header Fields ...............................37

6 Response................................................38

6.1 Status-Line .........................................38

6.1.1 Status Code and Reason Phrase ....................39

6.2 Response Header Fields ..............................41

7 Entity..................................................41

7.1 Entity Header Fields ................................41

7.2 Entity Body .........................................42

7.2.1 Type .............................................42

7.2.2 Length ...........................................43

8 Connections.............................................43

8.1 Persistent Connections ..............................43

8.1.1 Purpose ..........................................43

8.1.2 Overall Operation ................................44

8.1.3 Proxy Servers ....................................45

8.1.4 Practical Considerations .........................45

8.2 Message Transmission Requirements ...................46

9 Method Definitions......................................48

9.1 Safe and Idempotent Methods .........................48

Fielding, et. al. Standards Track [Page 2]

RFC 2068 HTTP/1.1 January 1997

9.1.1 Safe Methods .....................................48

9.1.2 Idempotent Methods ...............................49

9.2 OPTIONS .............................................49

9.3 GET .................................................50

9.4 HEAD ................................................50

9.5 POST ................................................51

9.6 PUT .................................................52

9.7 DELETE ..............................................53

9.8 TRACE ...............................................53

10 Status Code Definitions................................53

10.1 Informational 1xx ..................................54

10.1.1 100 Continue ....................................54

10.1.2 101 Switching Protocols .........................54

10.2 Successful 2xx .....................................54

10.2.1 200 OK ..........................................54

10.2.2 201 Created .....................................55

10.2.3 202 Accepted ....................................55

10.2.4 203 Non-Authoritative Information ...............55

10.2.5 204 No Content ..................................55

10.2.6 205 Reset Content ...............................56

10.2.7 206 Partial Content .............................56

10.3 Redirection 3xx ....................................56

10.3.1 300 Multiple Choices ............................57

10.3.2 301 Moved Permanently ...........................57

10.3.3 302 Moved Temporarily ...........................58

10.3.4 303 See Other ...................................58

10.3.5 304 Not Modified ................................58

10.3.6 305 Use Proxy ...................................59

10.4 Client Error 4xx ...................................59

10.4.1 400 Bad Request .................................60

10.4.2 401 Unauthorized ................................60

10.4.3 402 Payment Required ............................60

10.4.4 403 Forbidden ...................................60

10.4.5 404 Not Found ...................................60

10.4.6 405 Method Not Allowed ..........................61

10.4.7 406 Not Acceptable ..............................61

10.4.8 407 Proxy Authentication Required ...............61

10.4.9 408 Request Timeout .............................62

10.4.10 409 Conflict ...................................62

10.4.11 410 Gone .......................................62

10.4.12 411 Length Required ............................63

10.4.13 412 Precondition Failed ........................63

10.4.14 413 Request Entity Too Large ...................63

10.4.15 414 Request-URI Too Long .......................63

10.4.16 415 Unsupported Media Type .....................63

10.5 Server Error 5xx ...................................64

10.5.1 500 Internal Server Error .......................64

10.5.2 501 Not Implemented .............................64

Fielding, et. al. Standards Track [Page 3]

RFC 2068 HTTP/1.1 January 1997

10.5.3 502 Bad Gateway .................................64

10.5.4 503 Service Unavailable .........................64

10.5.5 504 Gateway Timeout .............................64

10.5.6 505 HTTP Version Not Supported ..................65

11 Access Authentication..................................65

11.1 Basic Authentication Scheme ........................66

11.2 Digest Authentication Scheme .......................67

12 Content Negotiation....................................67

12.1 Server-driven Negotiation ..........................68

12.2 Agent-driven Negotiation ...........................69

12.3 Transparent Negotiation ............................70

13 Caching in HTTP........................................70

13.1.1 Cache Correctness ...............................72

13.1.2 Warnings ........................................73

13.1.3 Cache-control Mechanisms ........................74

13.1.4 Explicit User Agent Warnings ....................74

13.1.5 Exceptions to the Rules and Warnings ............75

13.1.6 Client-controlled Behavior ......................75

13.2 Expiration Model ...................................75

13.2.1 Server-Specified Expiration .....................75

13.2.2 Heuristic Expiration ............................76

13.2.3 Age Calculations ................................77

13.2.4 Expiration Calculations .........................79

13.2.5 Disambiguating Expiration Values ................80

13.2.6 Disambiguating Multiple Responses ...............80

13.3 Validation Model ...................................81

13.3.1 Last-modified Dates .............................82

13.3.2 Entity Tag Cache Validators .....................82

13.3.3 Weak and Strong Validators ......................82

13.3.4 Rules for When to Use Entity Tags and Last-

modified Dates..........................................85

13.3.5 Non-validating Conditionals .....................86

13.4 Response Cachability ...............................86

13.5 Constructing Responses From Caches .................87

13.5.1 End-to-end and Hop-by-hop Headers ...............88

13.5.2 Non-modifiable Headers ..........................88

13.5.3 Combining Headers ...............................89

13.5.4 Combining Byte Ranges ...........................90

13.6 Caching Negotiated Responses .......................90

13.7 Shared and Non-Shared Caches .......................91

13.8 Errors or Incomplete Response Cache Behavior .......91

13.9 Side Effects of GET and HEAD .......................92

13.10 Invalidation After Updates or Deletions ...........92

13.11 Write-Through Mandatory ...........................93

13.12 Cache Replacement .................................93

13.13 History Lists .....................................93

14 Header Field Definitions...............................94

14.1 Accept .............................................95

Fielding, et. al. Standards Track [Page 4]

RFC 2068 HTTP/1.1 January 1997

14.2 Accept-Charset .....................................97

14.3 Accept-Encoding ....................................97

14.4 Accept-Language ....................................98

14.5 Accept-Ranges ......................................99

14.6 Age ................................................99

14.7 Allow .............................................100

14.8 Authorization .....................................100

14.9 Cache-Control .....................................101

14.9.1 What is Cachable ...............................103

14.9.2 What May be Stored by Caches ...................103

14.9.3 Modifications of the Basic Expiration Mechanism 104

14.9.4 Cache Revalidation and Reload Controls .........105

14.9.5 No-Transform Directive .........................107

14.9.6 Cache Control Extensions .......................108

14.10 Connection .......................................109

14.11 Content-Base .....................................109

14.12 Content-Encoding .................................110

14.13 Content-Language .................................110

14.14 Content-Length ...................................111

14.15 Content-Location .................................112

14.16 Content-MD5 ......................................113

14.17 Content-Range ....................................114

14.18 Content-Type .....................................116

14.19 Date .............................................116

14.20 ETag .............................................117

14.21 Expires ..........................................117

14.22 From .............................................118

14.23 Host .............................................119

14.24 If-Modified-Since ................................119

14.25 If-Match .........................................121

14.26 If-None-Match ....................................122

14.27 If-Range .........................................123

14.28 If-Unmodified-Since ..............................124

14.29 Last-Modified ....................................124

14.30 Location .........................................125

14.31 Max-Forwards .....................................125

14.32 Pragma ...........................................126

14.33 Proxy-Authenticate ...............................127

14.34 Proxy-Authorization ..............................127

14.35 Public ...........................................127

14.36 Range ............................................128

14.36.1 Byte Ranges ...................................128

14.36.2 Range Retrieval Requests ......................130

14.37 Referer ..........................................131

14.38 Retry-After ......................................131

14.39 Server ...........................................132

14.40 Transfer-Encoding ................................132

14.41 Upgrade ..........................................132

Fielding, et. al. Standards Track [Page 5]

RFC 2068 HTTP/1.1 January 1997

14.42 User-Agent .......................................134

14.43 Vary .............................................134

14.44 Via ..............................................135

14.45 Warning ..........................................137

14.46 WWW-Authenticate .................................139

15 Security Considerations...............................139

15.1 Authentication of Clients .........................139

15.2 Offering a Choice of Authentication Schemes .......140

15.3 Abuse of Server Log Information ...................141

15.4 Transfer of Sensitive Information .................141

15.5 Attacks Based On File and Path Names ..............142

15.6 Personal Information ..............................143

15.7 Privacy Issues Connected to Accept Headers ........143

15.8 DNS Spoofing ......................................144

15.9 Location Headers and Spoofing .....................144

16 Acknowledgments.......................................144

17 References............................................146

18 Authors' Addresses....................................149

19 Appendices............................................150

19.1 Internet Media Type message/http ..................150

19.2 Internet Media Type multipart/byteranges ..........150

19.3 Tolerant Applications .............................151

19.4 Differences Between HTTP Entities and

MIME Entities...........................................152

19.4.1 Conversion to Canonical Form ...................152

19.4.2 Conversion of Date Formats .....................153

19.4.3 Introduction of Content-Encoding ...............153

19.4.4 No Content-Transfer-Encoding ...................153

19.4.5 HTTP Header Fields in Multipart Body-Parts .....153

19.4.6 Introduction of Transfer-Encoding ..............154

19.4.7 MIME-Version ...................................154

19.5 Changes from HTTP/1.0 .............................154

19.5.1 Changes to Simplify Multi-homed Web Servers and

Conserve IP Addresses .................................155

19.6 Additional Features ...............................156

19.6.1 Additional Request Methods .....................156

19.6.2 Additional Header Field Definitions ............156

19.7 Compatibility with Previous Versions ..............160

19.7.1 Compatibility with HTTP/1.0 Persistent

Connections............................................161

Fielding, et. al. Standards Track [Page 6]

RFC 2068 HTTP/1.1 January 1997

1 Introduction

1.1 Purpose

The Hypertext Transfer Protocol (HTTP) is an application-level

protocol for distributed, collaborative, hypermedia information

systems. HTTP has been in use by the World-Wide Web global

information initiative since 1990. The first version of HTTP,

referred to as HTTP/0.9, was a simple protocol for raw data transfer

across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved

the protocol by allowing messages to be in the format of MIME-like

messages, containing metainformation about the data transferred and

modifiers on the request/response semantics. However, HTTP/1.0 does

not sufficiently take into consideration the effects of hierarchical

proxies, caching, the need for persistent connections, and virtual

hosts. In addition, the proliferation of incompletely-implemented

applications calling themselves "HTTP/1.0" has necessitated a

protocol version change in order for two communicating applications

to determine each other's true capabilities.

This specification defines the protocol referred to as "HTTP/1.1".

This protocol includes more stringent requirements than HTTP/1.0 in

order to ensure reliable implementation of its features.

Practical information systems require more functionality than simple

retrieval, including search, front-end update, and annotation. HTTP

allows an open-ended set of methods that indicate the purpose of a

request. It builds on the discipline of reference provided by the

Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or

name (URN) , for indicating the resource to which a method is to be

applied. Messages are passed in a format similar to that used by

Internet mail as defined by the Multipurpose Internet Mail Extensions

(MIME).

HTTP is also used as a generic protocol for communication between

user agents and proxies/gateways to other Internet systems, including

those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],

and WAIS [10] protocols. In this way, HTTP allows basic hypermedia

access to resources available from diverse applications.

1.2 Requirements

This specification uses the same words as RFC 1123 [8] for defining

the significance of each particular requirement. These words are:

MUST

This word or the adjective "required" means that the item is an

absolute requirement of the specification.

Fielding, et. al. Standards Track [Page 7]

RFC 2068 HTTP/1.1 January 1997

SHOULD

This word or the adjective "recommended" means that there may

exist valid reasons in particular circumstances to ignore this

item, but the full implications should be understood and the case

carefully weighed before choosing a different course.

MAY

This word or the adjective "optional" means that this item is

truly optional. One vendor may choose to include the item because

a particular marketplace requires it or because it enhances the

product, for example; another vendor may omit the same item.

An implementation is not compliant if it fails to satisfy one or more

of the MUST requirements for the protocols it implements. An

implementation that satisfies all the MUST and all the SHOULD

requirements for its protocols is said to be "unconditionally

compliant"; one that satisfies all the MUST requirements but not all

the SHOULD requirements for its protocols is said to be

"conditionally compliant."

1.3 Terminology

This specification uses a number of terms to refer to the roles

played by participants in, and objects of, the HTTP communication.

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,

resolutions) or vary in other ways.

Fielding, et. al. Standards Track [Page 8]

RFC 2068 HTTP/1.1 January 1997

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 `variant.' 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.

Fielding, et. al. Standards Track [Page 9]

RFC 2068 HTTP/1.1 January 1997

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.

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 cachable 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.

cachable

A response is cachable if a cache is allowed to store a copy of

the response message for use in answering subsequent requests. The

rules for determining the cachability of HTTP responses are

defined in section 13. Even if a resource is cachable, 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.

Fielding, et. al. Standards Track [Page 10]

RFC 2068 HTTP/1.1 January 1997

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.

1.4 Overall Operation

The HTTP protocol is a request/response protocol. A client sends a

request to the server in the form of a request method, URI, and

protocol version, followed by a MIME-like message containing request

modifiers, client information, and possible body content over a

connection with a server. The server responds with a status line,

including the message's protocol version and a success or error code,

followed by a MIME-like message containing server information, entity

metainformation, and possible entity-body content. The relationship

between HTTP and MIME is described in appendix 19.4.

Fielding, et. al. Standards Track [Page 11]

RFC 2068 HTTP/1.1 January 1997

Most HTTP communication is initiated by a user agent and consists of

a request to be applied to a resource on some origin server. In the

simplest case, this may be accomplished via a single connection (v)

between the user agent (UA) and the origin server (O).

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

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

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

A more complicated situation occurs when one or more intermediaries

are present in the request/response chain. There are three common

forms of intermediary: proxy, gateway, and tunnel. A proxy is a

forwarding agent, receiving requests for a URI in its absolute form,

rewriting all or part of the message, and forwarding the reformatted

request toward the server identified by the URI. A gateway is a

receiving agent, acting as a layer above some other server(s) and, if

necessary, translating the requests to the underlying server's

protocol. A tunnel acts as a relay point between two connections

without changing the messages; tunnels are used when the

communication needs to pass through an intermediary (such as a

firewall) even when the intermediary cannot understand the contents

of the messages.

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

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

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

The figure above shows three intermediaries (A, B, and C) between the

user agent and origin server. A request or response message that

travels the whole chain will pass through four separate connections.

This distinction is important because some HTTP communication options

may apply only to the connection with the nearest, non-tunnel

neighbor, only to the end-points of the chain, or to all connections

along the chain. Although the diagram is linear, each participant

may be engaged in multiple, simultaneous communications. For example,

B may be receiving requests from many clients other than A, and/or

forwarding requests to servers other than C, at the same time that it

is handling A's request.

Any party to the communication which is not acting as a tunnel may

employ an internal cache for handling requests. The effect of a cache

is that the request/response chain is shortened if one of the

participants along the chain has a cached response applicable to that

request. The following illustrates the resulting chain if B has a

cached copy of an earlier response from O (via C) for a request which

has not been cached by UA or A.

Fielding, et. al. Standards Track [Page 12]

RFC 2068 HTTP/1.1 January 1997

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

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

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

Not all responses are usefully cachable, and some requests may

contain modifiers which place special requirements on cache behavior.

HTTP requirements for cache behavior and cachable responses are

defined in section 13.

In fact, there are a wide variety of architectures and configurations

of caches and proxies currently being experimented with or deployed

across the World Wide Web; these systems include national hierarchies

of proxy caches to save transoceanic bandwidth, systems that

broadcast or multicast cache entries, organizations that distribute

subsets of cached data via CD-ROM, and so on. HTTP systems are used

in corporate intranets over high-bandwidth links, and for access via

PDAs with low-power radio links and intermittent connectivity. The

goal of HTTP/1.1 is to support the wide diversity of configurations

already deployed while introducing protocol constructs that meet the

needs of those who build web applications that require high

reliability and, failing that, at least reliable indications of

failure.

HTTP communication usually takes place over TCP/IP connections. The

default port is TCP 80, but other ports can be used. This does not

preclude HTTP from being implemented on top of any other protocol on

the Internet, or on other networks. HTTP only presumes a reliable

transport; any protocol that provides such guarantees can be used;

the mapping of the HTTP/1.1 request and response structures onto the

transport data units of the protocol in question is outside the scope

of this specification.

In HTTP/1.0, most implementations used a new connection for each

request/response exchange. In HTTP/1.1, a connection may be used for

one or more request/response exchanges, although connections may be

closed for a variety of reasons (see section 8.1).

2 Notational Conventions and Generic Grammar

2.1 Augmented BNF

All of the mechanisms specified in this document are described in

both prose and an augmented Backus-Naur Form (BNF) similar to that

used by RFC 822 [9]. Implementers will need to be familiar with the

notation in order to understand this specification. The augmented BNF

includes the following constructs:

Fielding, et. al. Standards Track [Page 13]

RFC 2068 HTTP/1.1 January 1997

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. Whitespace 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 whitespace (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

Fielding, et. al. Standards Track [Page 14]

RFC 2068 HTTP/1.1 January 1997

谁翻译了别忘了给我发一份 : xzjxu@126.com

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有