http1.1---3 (轉)[@more@]

2068 HTTP/1.1 January 1997

The syntax and registry of HTTP language tags is the same as that
defined by RFC 1766 [1]. In summary, a language tag is composed of 1
or more parts: A primary language tag and a possibly empty series of
subtags:

language-tag = primary-tag *( "-" subtag )

primary-tag = 1*8ALPHA
subtag = 1*8ALPHA

Whitespace is not allowed within the tag and all tags are case-
insensitive. The name space of language tags is administered by the
IANA. Example tags include:

en, en-US, en-cockney, i-cherokee, x-pig-latin

where any two-letter primary-tag is an ISO 639 language abbreviation
and any two-letter initial subtag is an ISO 3166 country code. (The
last three tags above are not registered tags; all but the last are
examples of tags which could be registered in future.)

3.11 Entity Tags

Entity tags are used for comparing two or more entities from the same
requested re. HTTP/1.1 uses entity tags in the ETag (section
14.20), If-Match (section 14.25), If-None-Match (section 14.26), and
If-Range (section 14.27) header fields. The definition of how they
are used and compared as cache validators is in section 13.3.3. An
entity tag consists of an opaque quoted string, possibly prefixed by
a weakness indicator.

entity-tag = [ weak ] opaque-tag

weak = "W/"
opaque-tag = quoted-string

A "strong entity tag" may be shared by two entities of a resource
only if they are equivalent by octet equality.

A "weak entity tag," indicated by the "W/" prefix, may be shared by
two entities of a resource only if the entities are equivalent and
could be substituted for each other with no significant change in
semantics. A weak entity tag can only be used for weak comparison.

An entity tag MUST be unique across all versions of all entities
associated with a particular resource. A given entity tag value may
be used for entities obtained by requests on different URIs without
implying anything about the equivalence of those entities.

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

RFC 2068 HTTP/1.1 January 1997

3.12 Range Units

HTTP/1.1 allows a client to request that only part (a range of) the
response entity be included within the response. HTTP/1.1 uses range
units in the Range (section 14.36) and Content-Range (section 14.17)
header fields. An entity may be broken down into subranges according
to various structural units.

range-unit = bytes-unit | other-range-unit

bytes-unit = "bytes"
other-range-unit = token

The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
implementations may ignore ranges specified using other units.
HTTP/1.1 has been designed to allow implementations of applications
that do not depend on knowledge of ranges.

4 HTTP Message

4.1 Message Types

HTTP messages consist of requests from client to server and responses
from server to client.

HTTP-message = Request | Response ; HTTP/1.1 messages

Request (section 5) and Response (section 6) messages use the generic
message format of RFC 822 [9] for tranerring entities (the payload
of the message). Both types of message consist of a start-line, one
or more header fields (also known as "headers"), an empty line (i.e.,
a line with nothing preceding the CRLF) indicating the end of the
header fields, and an optional message-body.

generic-message = start-line
*message-header
CRLF
[ message-body ]

start-line = Request-Line | Status-Line

In the interest of robustness, servers SHOULD ignore any empty
line(s) received where a Request-Line is expected. In other s, if
the server is reading the protocol stream at the beginning of a
message and receives a CRLF first, it should ignore the CRLF.

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

RFC 2068 HTTP/1.1 January 1997

Note: certain gy HTTP/1.0 client implementations generate an
extra CRLF's after a POST request. To restate what is explicitly
forbidden by the BNF, an HTTP/1.1 client must not preface or follow
a request with an extra CRLF.

4.2 Message Headers

HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity-header (section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 [9]. Each header field consists
of a name followed by a colon (":") and the field value. Field names
are case-insensitive. The field value may be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications SHOULD follow "common form" when
generating HTTP constructs, since there might exist some
implementations that fail to accept anything beyond the common forms.

message-header = field-name ":" [ field-value ] CRLF

field-name = token
field-value = *( field-content | LWS )

field-content = and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>

The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.

Multiple message-header fields with the same field-name may be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list [i.e., #(values)].
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a MUST NOT
change the order of these field values when a message is forwarded.

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

RFC 2068 HTTP/1.1 January 1997

4.3 Message Body

The message-body (if any) of an HTTP message is used to carry the
entity-body associated with the request or response. The message-body
differs from the entity-body only when a transfer coding has been
applied, as indicated by the Transfer-Encoding header field (section
14.40).

message-body = entity-body
|

Transfer-Encoding MUST be used to indicate any transfer codings
applied by an application to ensure safe and proper transfer of the
message. Transfer-Encoding is a property of the message, not of the
entity, and thus can be added or removed by any application along the
request/response chain.

The rules for when a message-body is allowed in a message differ for
requests and responses.

The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers. A message-body MAY be included in a
request only when the request method (section 5.1.1) allows an
entity-body.

For response messages, whether or not a message-body is included with
a message is dependent on both the request method and the response
status code (section 6.1.1). All responses to the HEAD request method
MUST NOT include a message-body, even though the presence of entity-
header fields might lead one to believe they do. All 1xx
(informational), 204 (no content), and 304 (not modified) responses
MUST NOT include a message-body. All other responses do include a
message-body, although it may be of zero length.

4.4 Message Length

When a message-body is included with a message, the length of that
body is detened by one of the following (in order of precedence):

1. Any response message which MUST NOT include a message-body
(such as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in the
message.

2. If a Transfer-Encoding header field (section 14.40) is present and
indicates that the "chunked" transfer coding has been applied, then

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

RFC 2068 HTTP/1.1 January 1997

the length is defined by the chunked encoding (section 3.6).

3. If a Content-Length header field (section 14.14) is present, its
value in bytes represents the length of the message-body.

4. If the message uses the media type "multipart/byteranges", which is
self-delimiting, then that defines the length. This media type MUST
NOT be used unless the sender knows that the recipient can parse it;
the presence in a request of a Range header with multiple byte-range
specifiers implies that the client can parse multipart/byteranges
responses.

5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a response.)

For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
containing a message-body MUST include a valid Content-Length header
field unless the server is known to be HTTP/1.1 compliant. If a
request contains a message-body and a Content-Length is not given,
the server SHOULD respond with 400 (bad request) if it cannot
determine the length of the message, or with 411 (length required) if
it wishes to insist on receiving a valid Content-Length.

All HTTP/1.1 applications that receive entities MUST accept the
"chunked" transfer coding (section 3.6), thus allowing this mechanism
to be used for messages when the message length cannot be determined
in advance.

Messages MUST NOT include both a Content-Length header field and the
"chunked" transfer coding. If both are received, the Content-Length
MUST be ignored.

When a Content-Length is given in a message where a message-body is
allowed, its field value MUST exactly match the number of OCTETs in
the message-body. HTTP/1.1 user agents MUST notify the user when an
invalid length is received and detected.

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

RFC 2068 HTTP/1.1 January 1997

4.5 General Header Fields

There are a few header fields which have general applicability for
both request and response messages, but which do not apply to the
entity being transferred. These header fields apply only to the
message being transmitted.

General-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of general
header fields if all parties in the communication recognize them to
be general-header fields. Unrecognized header fields are treated as
entity-header fields.

5 Request

A request message from a client to a server includes, within the
first line of that message, the method to be applied to the resource,
the ntifier of the resource, and the protocol version in use.

Request = Request-Line ; Section 5.1
*( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2

5.1 Request-Line

The Request-Line begins with a method token, followed by the
Request-URI and the protocol version, and ending with CRLF. The
elements are separated by SP characters. No CR or LF are allowed
except in the final CRLF sequence.

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

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

RFC 2068 HTTP/1.1 January 1997

5.1.1 Method

The Method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive.

extension-method = token

The list of methods allowed by a resource can be specified in an
Allow header field (section 14.7). The return code of the response
always notifies the client whether a method is currently allowed on a
resource, since the set of allowed methods can change dynamically.
Servers SHOULD return the status code 405 (Method Not Allowed) if the
method is known by the server but not allowed for the requested
resource, and 501 (Not Implemented) if the method is unrecognized or
not implemented by the server. The list of methods known by a server
can be listed in a Public response-header field (section 14.35).

The methods GET and HEAD MUST be supported by all general-purpose
servers. All other methods are optional; however, if the above
methods are implemented, they MUST be implemented with the same
semantics as those specified in section 9.

5.1.2 Request-URI

The Request-URI is a UnifoResource Identifier (section 3.2) and
identifies the resource upon which to apply the request.

Request-URI = "*" | absoluteURI | abs_path

The three options for Request-URI are dependent on the nature of the
request. The asterisk "*" means that the request does not apply to a
particular resource, but to the server itself, and is only allowed
when the method used does not necessarily apply to a resource. One
example would be

OPTIONS * HTTP/1.1

The absoluteURI form is required when the request is being made to a
proxy. The proxy is requested to forward the request or service it

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

RFC 2068 HTTP/1.1 January 1997

from a valid cache, and return the response. Note that the proxy MAY
forward the request on to another proxy or directly to the server
specified by the absoluteURI. In order to avoid request ls, a
proxy MUST be able to recognize all of its server names, including
any aliases, local variations, and the numeric address. An example
Request-Line would be:

GET HTTP/1.1

To allow for transition to absoluteURIs in all requests in future
versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.

The most common form of Request-URI is that used to identify a
resource on an origin server or gateway. In this case the absolute
path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
the Request-URI, and thework location of the URI_loc) MUST
be transmitted in a Host header field. For example, a client wishing
to retrieve the resource above directly from the origin server would
create a TCP connection to port 80 of the host "" and send
the lines:

GET /pub/WWW/TheProject.html HTTP/1.1
Host:

followed by the remainder of the Request. Note that the absolute path
cannot be empty; if none is present in the original URI, it MUST be
given as "/" (the server ).

If a proxy receives a request without any path in the Request-URI and
the method specified is capable of supporting the asterisk form of
request, then the last proxy on the request chain MUST forward the
request with "*" as the final Request-URI. For example, the request

OPTIONS HTTP/1.1

would be forwarded by the proxy as

OPTIONS * HTTP/1.1
Host:

after connecting to port 8001 of host "".

The Request-URI is transmitted in the format specified in section
3.2.1. The origin server MUST decode the Request-URI in order to
proy interpret the request. Servers SHOULD respond to invalid
Request-URIs with an appropriate status code.

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

RFC 2068 HTTP/1.1 January 1997

In requests that they forward, proxies MUST NOT rewrite the
"abs_path" part of a Request-URI in any way except as noted above to
replace a null abs_path with "*", no matter what the proxy does in
its internal implementation.

Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using a
non-reserved URL character for a reserved purpose. Implementers
should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI.

5.2 The Resource Identified by a Request

HTTP/1.1 origin servers SHOULD be aware that the exact resource
identified by an Internet request is determined by examining both the
Request-URI and the Host header field.

An origin server that does not allow resources to differ by the
requested host MAY ignore the Host header field value. (But see
section 19.5.1 for other requirements on Host support in HTTP/1.1.)

An origin server that does differentiate resources based on the host
requested (sometimes referred to as virtual hosts or vanity
hostnames) MUST use the following rules for determining the requested
resource on an HTTP/1.1 request:

1. If Request-URI is an absoluteURI, the host is part of the
Request-URI. Any Host header field value in the request MUST be
ignored.

2. If the Request-URI is not an absoluteURI, and the request
includes a Host header field, the host is determined by the Host
header field value.

3. If the host as determined by rule 1 or 2 is not a valid host on
the server, the response MUST be a 400 (Bad Request) error
message.

Recipients of an HTTP/1.0 request that lacks a Host header field MAY
attempt to use heuristics (e.g., examination of the URI path for
something unique to a particular host) in order to determine what
exact resource is being requested.

5.3 Request Header Fields

The request-header fields allow the client to pass additional
information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics

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

RFC 2068 HTTP/1.1 January 1997

equivalent to the parameters on a programming language method
invocation.

Request-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of request-
header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as
entity-header fields.

6 Response

After receiving and interpreting a request message, a server responds
with an HTTP response message.

Response = Status-Line ; Section 6.1
*( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2

6.1 Status-Line

The first line of a Response message is the Status-Line, consisting
of the protocol version followed by a numeric status code and its
associated textual phrase, with each element separated by SP
characters. No CR or LF is allowed except in the final CRLF
sequence.

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

RFC 2068 HTTP/1.1 January 1997

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status Code and Reason Phrase

The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully
defined in section 10. The Reason-Phrase is intended to give a short
textual description of the Status-Code. The Status-Code is intended
for use by automata and the Reason-Phrase is intended for the human
user. The client is not required to examine or display the Reason-
Phrase.

The first digit of the Status-Code defines the class of response. The
last two digits do not have any categorization role. There are 5
values for the first digit:

o 1xx: Informational - Request received, continuing process

o 2xx: Success - The action was successfully received, understood,
and accepted

o 3xx: Redirection - Further action must be taken in order to
complete the request

o 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled

o 5xx: Server Error - The server failed to fulfill an apparently
valid request

The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only recommended
-- they may be replaced by local equivalents without affecting the
protocol.

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

RFC 2068 HTTP/1.1 January 1997

extension-code = 3DIGIT

Reason-Phrase = *

HTTP status codes are extensible. HTTP applications are not required
to understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, applications MUST
understand the class of any status code, as indicated by the first
digit, and treat any unrecognized response as being equivalent to the
x00 status code of that class, with the exception that an
unrecognized response MUST NOT be cached. For example, if an
unrecognized status code of 431 is received by the client, it can
safely assume that there was something wrong with its request and
treat the response as if it had received a 400 status code. In such
cases, user agents SHOULD present to the user the entity returned
with the response, since that entity is likely to include human-
readable information which will explain the unusual status.

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

RFC 2068 HTTP/1.1 January 1997

6.2 Response Header Fields

The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and about
further access to the resource identified by the Request-URI.

Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as
entity-header fields.

7 Entity

Request and Response messages MAY transfer an entity if not otherwise
restricted by the request method or response status code. An entity
consists of entity-header fields and an entity-body, although some
responses will only include the entity-headers.

In this section, both sender and recipient refer to either the client
or the server, depending on who sends and who receives the entity.

7.1 Entity Header Fields

Entity-header fields define optional metainformation about the
entity-body or, if no body is present, about the resource identified
by the request.

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

RFC 2068 HTTP/1.1 January 1997

extension-header = message-header

The extension-header mechanism allows additional entity-header fields
to be defined without changing the protocol, but these fields cannot
be assumed to be recognizable by the recipient. Unrecognized header
fields SHOULD be ignored by the recipient and forwarded by proxies.

7.2 Entity Body

The entity-body (if any) sent with an HTTP request or response is in
a format and encoding defined by the entity-header fields.

entity-body = *OCTET

An entity-body is only present in a message when a message-body is
present, as described in section 4.3. The entity-body is obtained
from the message-body by decoding any Transfer-Encoding that may have
been applied to ensure safe and proper transfer of the message.

7.2.1 Type

When an entity-body is included with a message, the data type of that
body is determined via the header fields Content-Type and Content-
Encoding. These define a two-layer, ordered encoding model:

entity-body := Content-Encoding( Content-Type( data ) )

Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.

誰翻譯了別忘了給我發一份 to:xzjxu@126.com">xzjxu@126.com

http1.1---3 (轉)

相關文章