分享
 
 
 

http1.1---8

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

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

RFC 2068 HTTP/1.1 January 1997

Authorization = "Authorization" ":" credentials

HTTP access authentication is described in section 11. If a request

is authenticated and a realm specified, the same credentials SHOULD

be valid for all other requests within this realm.

When a shared cache (see section 13.7) receives a request containing

an Authorization field, it MUST NOT return the corresponding response

as a reply to any other request, unless one of the following specific

exceptions holds:

1. If the response includes the "proxy-revalidate" Cache-Control

directive, the cache MAY use that response in replying to a

subsequent request, but a proxy cache MUST first revalidate it with

the origin server, using the request-headers from the new request

to allow the origin server to authenticate the new request.

2. If the response includes the "must-revalidate" Cache-Control

directive, the cache MAY use that response in replying to a

subsequent request, but all caches MUST first revalidate it with

the origin server, using the request-headers from the new request

to allow the origin server to authenticate the new request.

3. If the response includes the "public" Cache-Control directive, it

may be returned in reply to any subsequent request.

14.9 Cache-Control

The Cache-Control general-header field is used to specify directives

that MUST be obeyed by all caching mechanisms along the

request/response chain. The directives specify behavior intended to

prevent caches from adversely interfering with the request or

response. These directives typically override the default caching

algorithms. Cache directives are unidirectional in that the presence

of a directive in a request does not imply that the same directive

should be given in the response.

Note that HTTP/1.0 caches may not implement Cache-Control and may

only implement Pragma: no-cache (see section 14.32).

Cache directives must be passed through by a proxy or gateway

application, regardless of their significance to that application,

since the directives may be applicable to all recipients along the

request/response chain. It is not possible to specify a cache-

directive for a specific cache.

Cache-Control = "Cache-Control" ":" 1#cache-directive

cache-directive = cache-request-directive

| cache-response-directive

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

RFC 2068 HTTP/1.1 January 1997

cache-request-directive =

"no-cache" [ "=" <"> 1#field-name <"> ]

| "no-store"

| "max-age" "=" delta-seconds

| "max-stale" [ "=" delta-seconds ]

| "min-fresh" "=" delta-seconds

| "only-if-cached"

| cache-extension

cache-response-directive =

"public"

| "private" [ "=" <"> 1#field-name <"> ]

| "no-cache" [ "=" <"> 1#field-name <"> ]

| "no-store"

| "no-transform"

| "must-revalidate"

| "proxy-revalidate"

| "max-age" "=" delta-seconds

| cache-extension

cache-extension = token [ "=" ( token | quoted-string ) ]

When a directive appears without any 1#field-name parameter, the

directive applies to the entire request or response. When such a

directive appears with a 1#field-name parameter, it applies only to

the named field or fields, and not to the rest of the request or

response. This mechanism supports extensibility; implementations of

future versions of the HTTP protocol may apply these directives to

header fields not defined in HTTP/1.1.

The cache-control directives can be broken down into these general

categories:

o Restrictions on what is cachable; these may only be imposed by the

origin server.

o Restrictions on what may be stored by a cache; these may be imposed

by either the origin server or the user agent.

o Modifications of the basic expiration mechanism; these may be

imposed by either the origin server or the user agent.

o Controls over cache revalidation and reload; these may only be

imposed by a user agent.

o Control over transformation of entities.

o Extensions to the caching system.

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

RFC 2068 HTTP/1.1 January 1997

14.9.1 What is Cachable

By default, a response is cachable if the requirements of the request

method, request header fields, and the response status indicate that

it is cachable. Section 13.4 summarizes these defaults for

cachability. The following Cache-Control response directives allow an

origin server to override the default cachability of a response:

public

Indicates that the response is cachable by any cache, even if it

would normally be non-cachable or cachable only within a non-shared

cache. (See also Authorization, section 14.8, for additional

details.)

private

Indicates that all or part of the response message is intended for a

single user and MUST NOT be cached by a shared cache. This allows an

origin server to state that the specified parts of the response are

intended for only one user and are not a valid response for requests

by other users. A private (non-shared) cache may cache the response.

Note: This usage of the word private only controls where the

response may be cached, and cannot ensure the privacy of the

message content.

no-cache

Indicates that all or part of the response message MUST NOT be cached

anywhere. This allows an origin server to prevent caching even by

caches that have been configured to return stale responses to client

requests.

Note: Most HTTP/1.0 caches will not recognize or obey this

directive.

14.9.2 What May be Stored by Caches

The purpose of the no-store directive is to prevent the inadvertent

release or retention of sensitive information (for example, on backup

tapes). The no-store directive applies to the entire message, and may

be sent either in a response or in a request. If sent in a request, a

cache MUST NOT store any part of either this request or any response

to it. If sent in a response, a cache MUST NOT store any part of

either this response or the request that elicited it. This directive

applies to both non-shared and shared caches. "MUST NOT store" in

this context means that the cache MUST NOT intentionally store the

information in non-volatile storage, and MUST make a best-effort

attempt to remove the information from volatile storage as promptly

as possible after forwarding it.

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

RFC 2068 HTTP/1.1 January 1997

Even when this directive is associated with a response, users may

explicitly store such a response outside of the caching system (e.g.,

with a "Save As" dialog). History buffers may store such responses as

part of their normal operation.

The purpose of this directive is to meet the stated requirements of

certain users and service authors who are concerned about accidental

releases of information via unanticipated accesses to cache data

structures. While the use of this directive may improve privacy in

some cases, we caution that it is NOT in any way a reliable or

sufficient mechanism for ensuring privacy. In particular, malicious

or compromised caches may not recognize or obey this directive; and

communications networks may be vulnerable to eavesdropping.

14.9.3 Modifications of the Basic Expiration Mechanism

The expiration time of an entity may be specified by the origin

server using the Expires header (see section 14.21). Alternatively,

it may be specified using the max-age directive in a response.

If a response includes both an Expires header and a max-age

directive, the max-age directive overrides the Expires header, even

if the Expires header is more restrictive. This rule allows an origin

server to provide, for a given response, a longer expiration time to

an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be

useful if certain HTTP/1.0 caches improperly calculate ages or

expiration times, perhaps due to desynchronized clocks.

Note: most older caches, not compliant with this specification, do

not implement any Cache-Control directives. An origin server

wishing to use a Cache-Control directive that restricts, but does

not prevent, caching by an HTTP/1.1-compliant cache may exploit the

requirement that the max-age directive overrides the Expires

header, and the fact that non-HTTP/1.1-compliant caches do not

observe the max-age directive.

Other directives allow an user agent to modify the basic expiration

mechanism. These directives may be specified on a request:

max-age

Indicates that the client is willing to accept a response whose age

is no greater than the specified time in seconds. Unless max-stale

directive is also included, the client is not willing to accept a

stale response.

min-fresh

Indicates that the client is willing to accept a response whose

freshness lifetime is no less than its current age plus the

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

RFC 2068 HTTP/1.1 January 1997

specified time in seconds. That is, the client wants a response

that will still be fresh for at least the specified number of

seconds.

max-stale

Indicates that the client is willing to accept a response that has

exceeded its expiration time. If max-stale is assigned a value,

then the client is willing to accept a response that has exceeded

its expiration time by no more than the specified number of

seconds. If no value is assigned to max-stale, then the client is

willing to accept a stale response of any age.

If a cache returns a stale response, either because of a max-stale

directive on a request, or because the cache is configured to

override the expiration time of a response, the cache MUST attach a

Warning header to the stale response, using Warning 10 (Response is

stale).

14.9.4 Cache Revalidation and Reload Controls

Sometimes an user agent may want or need to insist that a cache

revalidate its cache entry with the origin server (and not just with

the next cache along the path to the origin server), or to reload its

cache entry from the origin server. End-to-end revalidation may be

necessary if either the cache or the origin server has overestimated

the expiration time of the cached response. End-to-end reload may be

necessary if the cache entry has become corrupted for some reason.

End-to-end revalidation may be requested either when the client does

not have its own local cached copy, in which case we call it

"unspecified end-to-end revalidation", or when the client does have a

local cached copy, in which case we call it "specific end-to-end

revalidation."

The client can specify these three kinds of action using Cache-

Control request directives:

End-to-end reload

The request includes a "no-cache" Cache-Control directive or, for

compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field

names may be included with the no-cache directive in a request. The

server MUST NOT use a cached copy when responding to such a

request.

Specific end-to-end revalidation

The request includes a "max-age=0" Cache-Control directive, which

forces each cache along the path to the origin server to revalidate

its own entry, if any, with the next cache or server. The initial

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

RFC 2068 HTTP/1.1 January 1997

request includes a cache-validating conditional with the client's

current validator.

Unspecified end-to-end revalidation

The request includes "max-age=0" Cache-Control directive, which

forces each cache along the path to the origin server to revalidate

its own entry, if any, with the next cache or server. The initial

request does not include a cache-validating conditional; the first

cache along the path (if any) that holds a cache entry for this

resource includes a cache-validating conditional with its current

validator.

When an intermediate cache is forced, by means of a max-age=0

directive, to revalidate its own cache entry, and the client has

supplied its own validator in the request, the supplied validator may

differ from the validator currently stored with the cache entry. In

this case, the cache may use either validator in making its own

request without affecting semantic transparency.

However, the choice of validator may affect performance. The best

approach is for the intermediate cache to use its own validator when

making its request. If the server replies with 304 (Not Modified),

then the cache should return its now validated copy to the client

with a 200 (OK) response. If the server replies with a new entity and

cache validator, however, the intermediate cache should compare the

returned validator with the one provided in the client's request,

using the strong comparison function. If the client's validator is

equal to the origin server's, then the intermediate cache simply

returns 304 (Not Modified). Otherwise, it returns the new entity with

a 200 (OK) response.

If a request includes the no-cache directive, it should not include

min-fresh, max-stale, or max-age.

In some cases, such as times of extremely poor network connectivity,

a client may want a cache to return only those responses that it

currently has stored, and not to reload or revalidate with the origin

server. To do this, the client may include the only-if-cached

directive in a request. If it receives this directive, a cache SHOULD

either respond using a cached entry that is consistent with the other

constraints of the request, or respond with a 504 (Gateway Timeout)

status. However, if a group of caches is being operated as a unified

system with good internal connectivity, such a request MAY be

forwarded within that group of caches.

Because a cache may be configured to ignore a server's specified

expiration time, and because a client request may include a max-stale

directive (which has a similar effect), the protocol also includes a

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

RFC 2068 HTTP/1.1 January 1997

mechanism for the origin server to require revalidation of a cache

entry on any subsequent use. When the must-revalidate directive is

present in a response received by a cache, that cache MUST NOT use

the entry after it becomes stale to respond to a subsequent request

without first revalidating it with the origin server. (I.e., the

cache must do an end-to-end revalidation every time, if, based solely

on the origin server's Expires or max-age value, the cached response

is stale.)

The must-revalidate directive is necessary to support reliable

operation for certain protocol features. In all circumstances an

HTTP/1.1 cache MUST obey the must-revalidate directive; in

particular, if the cache cannot reach the origin server for any

reason, it MUST generate a 504 (Gateway Timeout) response.

Servers should send the must-revalidate directive if and only if

failure to revalidate a request on the entity could result in

incorrect operation, such as a silently unexecuted financial

transaction. Recipients MUST NOT take any automated action that

violates this directive, and MUST NOT automatically provide an

unvalidated copy of the entity if revalidation fails.

Although this is not recommended, user agents operating under severe

connectivity constraints may violate this directive but, if so, MUST

explicitly warn the user that an unvalidated response has been

provided. The warning MUST be provided on each unvalidated access,

and SHOULD require explicit user confirmation.

The proxy-revalidate directive has the same meaning as the must-

revalidate directive, except that it does not apply to non-shared

user agent caches. It can be used on a response to an authenticated

request to permit the user's cache to store and later return the

response without needing to revalidate it (since it has already been

authenticated once by that user), while still requiring proxies that

service many users to revalidate each time (in order to make sure

that each user has been authenticated). Note that such authenticated

responses also need the public cache control directive in order to

allow them to be cached at all.

14.9.5 No-Transform Directive

Implementers of intermediate caches (proxies) have found it useful to

convert the media type of certain entity bodies. A proxy might, for

example, convert between image formats in order to save cache space

or to reduce the amount of traffic on a slow link. HTTP has to date

been silent on these transformations.

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

RFC 2068 HTTP/1.1 January 1997

Serious operational problems have already occurred, however, when

these transformations have been applied to entity bodies intended for

certain kinds of applications. For example, applications for medical

imaging, scientific data analysis and those using end-to-end

authentication, all depend on receiving an entity body that is bit

for bit identical to the original entity-body.

Therefore, if a response includes the no-transform directive, an

intermediate cache or proxy MUST NOT change those headers that are

listed in section 13.5.2 as being subject to the no-transform

directive. This implies that the cache or proxy must not change any

aspect of the entity-body that is specified by these headers.

14.9.6 Cache Control Extensions

The Cache-Control header field can be extended through the use of one

or more cache-extension tokens, each with an optional assigned value.

Informational extensions (those which do not require a change in

cache behavior) may be added without changing the semantics of other

directives. Behavioral extensions are designed to work by acting as

modifiers to the existing base of cache directives. Both the new

directive and the standard directive are supplied, such that

applications which do not understand the new directive will default

to the behavior specified by the standard directive, and those that

understand the new directive will recognize it as modifying the

requirements associated with the standard directive. In this way,

extensions to the Cache-Control directives can be made without

requiring changes to the base protocol.

This extension mechanism depends on a HTTP cache obeying all of the

cache-control directives defined for its native HTTP-version, obeying

certain extensions, and ignoring all directives that it does not

understand.

For example, consider a hypothetical new response directive called

"community" which acts as a modifier to the "private" directive. We

define this new directive to mean that, in addition to any non-shared

cache, any cache which is shared only by members of the community

named within its value may cache the response. An origin server

wishing to allow the "UCI" community to use an otherwise private

response in their shared cache(s) may do so by including

Cache-Control: private, community="UCI"

A cache seeing this header field will act correctly even if the cache

does not understand the "community" cache-extension, since it will

also see and understand the "private" directive and thus default to

the safe behavior.

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

RFC 2068 HTTP/1.1 January 1997

Unrecognized cache-directives MUST be ignored; it is assumed that any

cache-directive likely to be unrecognized by an HTTP/1.1 cache will

be combined with standard directives (or the response's default

cachability) such that the cache behavior will remain minimally

correct even if the cache does not understand the extension(s).

14.10 Connection

The Connection general-header field allows the sender to specify

options that are desired for that particular connection and MUST NOT

be communicated by proxies over further connections.

The Connection header has the following grammar:

Connection-header = "Connection" ":" 1#(connection-token)

connection-token = token

HTTP/1.1 proxies MUST parse the Connection header field before a

message is forwarded and, for each connection-token in this field,

remove any header field(s) from the message with the same name as the

connection-token. Connection options are signaled by the presence of

a connection-token in the Connection header field, not by any

corresponding additional header field(s), since the additional header

field may not be sent if there are no parameters associated with that

connection option. HTTP/1.1 defines the "close" connection option

for the sender to signal that the connection will be closed after

completion of the response. For example,

Connection: close

in either the request or the response header fields indicates that

the connection should not be considered `persistent' (section 8.1)

after the current request/response is complete.

HTTP/1.1 applications that do not support persistent connections MUST

include the "close" connection option in every message.

14.11 Content-Base

The Content-Base entity-header field may be used to specify the base

URI for resolving relative URLs within the entity. This header field

is described as Base in RFC 1808, which is expected to be revised.

Content-Base = "Content-Base" ":" absoluteURI

If no Content-Base field is present, the base URI of an entity is

defined either by its Content-Location (if that Content-Location URI

is an absolute URI) or the URI used to initiate the request, in that

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

RFC 2068 HTTP/1.1 January 1997

order of precedence. Note, however, that the base URI of the contents

within the entity-body may be redefined within that entity-body.

14.12 Content-Encoding

The Content-Encoding entity-header field is used as a modifier to the

media-type. When present, its value indicates what additional content

codings have been applied to the entity-body, and thus what decoding

mechanisms MUST be applied in order to obtain the media-type

referenced by the Content-Type header field. Content-Encoding is

primarily used to allow a document to be compressed without losing

the identity of its underlying media type.

Content-Encoding = "Content-Encoding" ":" 1#content-coding

Content codings are defined in section 3.5. An example of its use is

Content-Encoding: gzip

The Content-Encoding is a characteristic of the entity identified by

the Request-URI. Typically, the entity-body is stored with this

encoding and is only decoded before rendering or analogous usage.

If multiple encodings have been applied to an entity, the content

codings MUST be listed in the order in which they were applied.

Additional information about the encoding parameters MAY be provided

by other entity-header fields not defined by this specification.

14.13 Content-Language

The Content-Language entity-header field describes the natural

language(s) of the intended audience for the enclosed entity. Note

that this may not be equivalent to all the languages used within the

entity-body.

Content-Language = "Content-Language" ":" 1#language-tag

Language tags are defined in section 3.10. The primary purpose of

Content-Language is to allow a user to identify and differentiate

entities according to the user's own preferred language. Thus, if the

body content is intended only for a Danish-literate audience, the

appropriate field is

Content-Language: da

If no Content-Language is specified, the default is that the content

is intended for all language audiences. This may mean that the sender

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

RFC 2068 HTTP/1.1 January 1997

does not consider it to be specific to any natural language, or that

the sender does not know for which language it is intended.

Multiple languages MAY be listed for content that is intended for

multiple audiences. For example, a rendition of the "Treaty of

Waitangi," presented simultaneously in the original Maori and English

versions, would call for

Content-Language: mi, en

However, just because multiple languages are present within an entity

does not mean that it is intended for multiple linguistic audiences.

An example would be a beginner's language primer, such as "A First

Lesson in Latin," which is clearly intended to be used by an

English-literate audience. In this case, the Content-Language should

only include "en".

Content-Language may be applied to any media type -- it is not

limited to textual documents.

14.14 Content-Length

The Content-Length entity-header field indicates the size of the

message-body, in decimal number of octets, sent to the recipient or,

in the case of the HEAD method, the size of the entity-body that

would have been sent had the request been a GET.

Content-Length = "Content-Length" ":" 1*DIGIT

An example is

Content-Length: 3495

Applications SHOULD use this field to indicate the size of the

message-body to be transferred, regardless of the media type of the

entity. It must be possible for the recipient to reliably determine

the end of HTTP/1.1 requests containing an entity-body, e.g., because

the request has a valid Content-Length field, uses Transfer-Encoding:

chunked or a multipart body.

Any Content-Length greater than or equal to zero is a valid value.

Section 4.4 describes how to determine the length of a message-body

if a Content-Length is not given.

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

RFC 2068 HTTP/1.1 January 1997

Note: The meaning of this field is significantly different from the

corresponding definition in MIME, where it is an optional field

used within the "message/external-body" content-type. In HTTP, it

SHOULD be sent whenever the message's length can be determined

prior to being transferred.

14.15 Content-Location

The Content-Location entity-header field may be used to supply the

resource location for the entity enclosed in the message. In the case

where a resource has multiple entities associated with it, and those

entities actually have separate locations by which they might be

individually accessed, the server should provide a Content-Location

for the particular variant which is returned. In addition, a server

SHOULD provide a Content-Location for the resource corresponding to

the response entity.

Content-Location = "Content-Location" ":"

( absoluteURI | relativeURI )

If no Content-Base header field is present, the value of Content-

Location also defines the base URL for the entity (see section

14.11).

The Content-Location value is not a replacement for the original

requested URI; it is only a statement of the location of the resource

corresponding to this particular entity at the time of the request.

Future requests MAY use the Content-Location URI if the desire is to

identify the source of that particular entity.

A cache cannot assume that an entity with a Content-Location

different from the URI used to retrieve it can be used to respond to

later requests on that Content-Location URI. However, the Content-

Location can be used to differentiate between multiple entities

retrieved from a single requested resource, as described in section

13.6.

If the Content-Location is a relative URI, the URI is interpreted

relative to any Content-Base URI provided in the response. If no

Content-Base is provided, the relative URI is interpreted relative to

the Request-URI.

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

RFC 2068 HTTP/1.1 January 1997

14.16 Content-MD5

The Content-MD5 entity-header field, as defined in RFC 1864 [23], is

an MD5 digest of the entity-body for the purpose of providing an

end-to-end message integrity check (MIC) of the entity-body. (Note: a

MIC is good for detecting accidental modification of the entity-body

in transit, but is not proof against malicious attacks.)

Content-MD5 = "Content-MD5" ":" md5-digest

md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>

The Content-MD5 header field may be generated by an origin server to

function as an integrity check of the entity-body. Only origin

servers may generate the Content-MD5 header field; proxies and

gateways MUST NOT generate it, as this would defeat its value as an

end-to-end integrity check. Any recipient of the entity-body,

including gateways and proxies, MAY check that the digest value in

this header field matches that of the entity-body as received.

The MD5 digest is computed based on the content of the entity-body,

including any Content-Encoding that has been applied, but not

including any Transfer-Encoding that may have been applied to the

message-body. If the message is received with a Transfer-Encoding,

that encoding must be removed prior to checking the Content-MD5 value

against the received entity.

This has the result that the digest is computed on the octets of the

entity-body exactly as, and in the order that, they would be sent if

no Transfer-Encoding were being applied.

HTTP extends RFC 1864 to permit the digest to be computed for MIME

composite media-types (e.g., multipart/* and message/rfc822), but

this does not change how the digest is computed as defined in the

preceding paragraph.

Note: There are several consequences of this. The entity-body for

composite types may contain many body-parts, each with its own MIME

and HTTP headers (including Content-MD5, Content-Transfer-Encoding,

and Content-Encoding headers). If a body-part has a Content-

Transfer-Encoding or Content-Encoding header, it is assumed that

the content of the body-part has had the encoding applied, and the

body-part is included in the Content-MD5 digest as is -- i.e.,

after the application. The Transfer-Encoding header field is not

allowed within body-parts.

Note: while the definition of Content-MD5 is exactly the same for

HTTP as in RFC 1864 for MIME entity-bodies, there are several ways

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

RFC 2068 HTTP/1.1 January 1997

in which the application of Content-MD5 to HTTP entity-bodies

differs from its application to MIME entity-bodies. One is that

HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does

use Transfer-Encoding and Content-Encoding. Another is that HTTP

more frequently uses binary content types than MIME, so it is worth

noting that, in such cases, the byte order used to compute the

digest is the transmission byte order defined for the type. Lastly,

HTTP allows transmission of text types with any of several line

break conventions and not just the canonical form using CRLF.

Conversion of all line breaks to CRLF should not be done before

computing or checking the digest: the line break convention used in

the text actually transmitted should be left unaltered when

computing the digest.

14.17 Content-Range

The Content-Range entity-header is sent with a partial entity-body to

specify where in the full entity-body the partial body should be

inserted. It also indicates the total size of the full entity-body.

When a server returns a partial response to a client, it must

describe both the extent of the range covered by the response, and

the length of the entire entity-body.

Content-Range = "Content-Range" ":" content-range-spec

content-range-spec = byte-content-range-spec

byte-content-range-spec = bytes-unit SP first-byte-pos "-"

last-byte-pos "/" entity-length

entity-length = 1*DIGIT

Unlike byte-ranges-specifier values, a byte-content-range-spec may

only specify one range, and must contain absolute byte positions for

both the first and last byte of the range.

A byte-content-range-spec whose last-byte-pos value is less than its

first-byte-pos value, or whose entity-length value is less than or

equal to its last-byte-pos value, is invalid. The recipient of an

invalid byte-content-range-spec MUST ignore it and any content

transferred along with it.

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

RFC 2068 HTTP/1.1 January 1997

Examples of byte-content-range-spec values, assuming that the entity

contains a total of 1234 bytes:

o The first 500 bytes:

bytes 0-499/1234

o The second 500 bytes:

bytes 500-999/1234

o All except for the first 500 bytes:

bytes 500-1233/1234

o The last 500 bytes:

bytes 734-1233/1234

When an HTTP message includes the content of a single range (for

example, a response to a request for a single range, or to a request

for a set of ranges that overlap without any holes), this content is

transmitted with a Content-Range header, and a Content-Length header

showing the number of bytes actually transferred. For example,

HTTP/1.1 206 Partial content

Date: Wed, 15 Nov 1995 06:25:24 GMT

Last-modified: Wed, 15 Nov 1995 04:58:08 GMT

Content-Range: bytes 21010-47021/47022

Content-Length: 26012

Content-Type: image/gif

When an HTTP message includes the content of multiple ranges (for

example, a response to a request for multiple non-overlapping

ranges), these are transmitted as a multipart MIME message. The

multipart MIME content-type used for this purpose is defined in this

specification to be "multipart/byteranges". See appendix 19.2 for its

definition.

A client that cannot decode a MIME multipart/byteranges message

should not ask for multiple byte-ranges in a single request.

When a client requests multiple byte-ranges in one request, the

server SHOULD return them in the order that they appeared in the

request.

If the server ignores a byte-range-spec because it is invalid, the

server should treat the request as if the invalid Range header field

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

RFC 2068 HTTP/1.1 January 1997

did not exist. (Normally, this means return a 200 response containing

the full entity). The reason is that the only time a client will make

such an invalid request is when the entity is smaller than the entity

retrieved by a prior request.

14.18 Content-Type

The Content-Type entity-header field indicates the media type of the

entity-body sent to the recipient or, in the case of the HEAD method,

the media type that would have been sent had the request been a GET.

Content-Type = "Content-Type" ":" media-type

Media types are defined in section 3.7. An example of the field is

Content-Type: text/html; charset=ISO-8859-4

Further discussion of methods for identifying the media type of an

entity is provided in section 7.2.1.

14.19 Date

The Date general-header field represents the date and time at which

the message was originated, having the same semantics as orig-date in

RFC 822. The field value is an HTTP-date, as described in section

3.3.1.

Date = "Date" ":" HTTP-date

An example is

Date: Tue, 15 Nov 1994 08:12:31 GMT

If a message is received via direct connection with the user agent

(in the case of requests) or the origin server (in the case of

responses), then the date can be assumed to be the current date at

the receiving end. However, since the date--as it is believed by the

origin--is important for evaluating cached responses, origin servers

MUST include a Date header field in all responses. Clients SHOULD

only send a Date header field in messages that include an entity-

body, as in the case of the PUT and POST requests, and even then it

is optional. A received message which does not have a Date header

field SHOULD be assigned one by the recipient if the message will be

cached by that recipient or gatewayed via a protocol which requires a

Date.

谁翻译了别忘了给我发一份 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- 王朝網路 版權所有