软件工程

本类阅读TOP10

·PHP4 + MYSQL + APACHE 在 WIN 系统下的安装、配置
·Linux 入门常用命令(1)
·Linux 入门常用命令(2)
·使用 DCPROMO/FORCEREMOVAL 命令强制将 Active Directory 域控制器降级
·DirectShow学习(八): CBaseRender类及相应Pin类的源代码分析
·基于ICE方式SIP信令穿透Symmetric NAT技术研究
·Windows 2003网络负载均衡的实现
·一网打尽Win十四种系统故障解决方法
·数百种 Windows 软件的免费替代品列表
·收藏---行百里半九十

分类导航
VC语言Delphi
VB语言ASP
PerlJava
Script数据库
其他语言游戏开发
文件格式网站制作
软件工程.NET开发
http1.1---7

作者:未知 来源:月光软件站 加入时间:2005-2-28 月光软件站

 

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

RFC 2068                        HTTP/1.1                    January 1997


     o  If only a Last-Modified value has been provided by the origin
        server, SHOULD use that value in non-subrange cache-conditional
        requests (using If-Modified-Since).
     o  If only a Last-Modified value has been provided by an HTTP/1.0
        origin server, MAY use that value in subrange cache-conditional
        requests (using If-Unmodified-Since:). The user agent should
        provide a way to disable this, in case of difficulty.
     o  If both an entity tag and a Last-Modified value have been
        provided by the origin server, SHOULD use both validators in
        cache-conditional requests. This allows both HTTP/1.0 and
        HTTP/1.1 caches to respond appropriately.

   An HTTP/1.1 cache, upon receiving a request, MUST use the most
   restrictive validator when deciding whether the client's cache entry
   matches the cache's own cache entry. This is only an issue when the
   request contains both an entity tag and a last-modified-date
   validator (If-Modified-Since or If-Unmodified-Since).

     A note on rationale: The general principle behind these rules is
     that HTTP/1.1 servers and clients should transmit as much non-
     redundant information as is available in their responses and
     requests. HTTP/1.1 systems receiving this information will make the
     most conservative assumptions about the validators they receive.

     HTTP/1.0 clients and caches will ignore entity tags. Generally,
     last-modified values received or used by these systems will support
     transparent and efficient caching, and so HTTP/1.1 origin servers
     should provide Last-Modified values. In those rare cases where the
     use of a Last-Modified value as a validator by an HTTP/1.0 system
     could result in a serious problem, then HTTP/1.1 origin servers
     should not provide one.

13.3.5 Non-validating Conditionals

   The principle behind entity tags is that only the service author
   knows the semantics of a resource well enough to select an
   appropriate cache validation mechanism, and the specification of any
   validator comparison function more complex than byte-equality would
   open up a can of worms.  Thus, comparisons of any other headers
   (except Last-Modified, for compatibility with HTTP/1.0) are never
   used for purposes of validating a cache entry.

13.4 Response Cachability

   Unless specifically constrained by a Cache-Control (section 14.9)
   directive, a caching system may always store a successful response
   (see section 13.8) as a cache entry, may return it without validation
   if it is fresh, and may return it after successful validation. If

 

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

RFC 2068                        HTTP/1.1                    January 1997


   there is neither a cache validator nor an explicit expiration time
   associated with a response, we do not expect it to be cached, but
   certain caches may violate this expectation (for example, when little
   or no network connectivity is available). A client can usually detect
   that such a response was taken from a cache by comparing the Date
   header to the current time.

     Note that some HTTP/1.0 caches are known to violate this
     expectation without providing any Warning.

   However, in some cases it may be inappropriate for a cache to retain
   an entity, or to return it in response to a subsequent request. This
   may be because absolute semantic transparency is deemed necessary by
   the service author, or because of security or privacy considerations.
   Certain Cache-Control directives are therefore provided so that the
   server can indicate that certain resource entities, or portions
   thereof, may not be cached regardless of other considerations.

   Note that section 14.8 normally prevents a shared cache from saving
   and returning a response to a previous request if that request
   included an Authorization header.

   A response received with a status code of 200, 203, 206, 300, 301 or
   410 may be stored by a cache and used in reply to a subsequent
   request, subject to the expiration mechanism, unless a Cache-Control
   directive prohibits caching. However, a cache that does not support
   the Range and Content-Range headers MUST NOT cache 206 (Partial
   Content) responses.

   A response received with any other status code MUST NOT be returned
   in a reply to a subsequent request unless there are Cache-Control
   directives or another header(s) that explicitly allow it. For
   example, these include the following: an Expires header (section
   14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public"
   or "private" Cache-Control directive (section 14.9).

13.5 Constructing Responses From Caches

   The purpose of an HTTP cache is to store information received in
   response to requests, for use in responding to future requests. In
   many cases, a cache simply returns the appropriate parts of a
   response to the requester. However, if the cache holds a cache entry
   based on a previous response, it may have to combine parts of a new
   response with what is held in the cache entry.

 

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


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

   For the purpose of defining the behavior of caches and non-caching
   proxies, we divide HTTP headers into two categories:

  o  End-to-end headers, which must be transmitted to the
     ultimate recipient of a request or response. End-to-end
     headers in responses must be stored as part of a cache entry
     and transmitted in any response formed from a cache entry.
  o  Hop-by-hop headers, which are meaningful only for a single
     transport-level connection, and are not stored by caches or
     forwarded by proxies.

   The following HTTP/1.1 headers are hop-by-hop headers:

     o  Connection
     o  Keep-Alive
     o  Public
     o  Proxy-Authenticate
     o  Transfer-Encoding
     o  Upgrade

   All other headers defined by HTTP/1.1 are end-to-end headers.

   Hop-by-hop headers introduced in future versions of HTTP MUST be
   listed in a Connection header, as described in section 14.10.

13.5.2 Non-modifiable Headers

   Some features of the HTTP/1.1 protocol, such as Digest
   Authentication, depend on the value of certain end-to-end headers. A
   cache or non-caching proxy SHOULD NOT modify an end-to-end header
   unless the definition of that header requires or specifically allows
   that.

   A cache or non-caching proxy MUST NOT modify any of the following
   fields in a request or response, nor may it add any of these fields
   if not already present:

     o  Content-Location
     o  ETag
     o  Expires
     o  Last-Modified

 

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


   A cache or non-caching proxy MUST NOT modify or add any of the
   following fields in a response that contains the no-transform Cache-
   Control directive, or in any request:

     o  Content-Encoding
     o  Content-Length
     o  Content-Range
     o  Content-Type

   A cache or non-caching proxy MAY modify or add these fields in a
   response that does not include no-transform, but if it does so, it
   MUST add a Warning 14 (Transformation applied) if one does not
   already appear in the response.

     Warning: unnecessary modification of end-to-end headers may cause
     authentication failures if stronger authentication mechanisms are
     introduced in later versions of HTTP. Such authentication
     mechanisms may rely on the values of header fields not listed here.

13.5.3 Combining Headers

   When a cache makes a validating request to a server, and the server
   provides a 304 (Not Modified) response, the cache must construct a
   response to send to the requesting client. The cache uses the
   entity-body stored in the cache entry as the entity-body of this
   outgoing response. The end-to-end headers stored in the cache entry
   are used for the constructed response, except that any end-to-end
   headers provided in the 304 response MUST replace the corresponding
   headers from the cache entry. Unless the cache decides to remove the
   cache entry, it MUST also replace the end-to-end headers stored with
   the cache entry with corresponding headers received in the incoming
   response.

   In other words, the set of end-to-end headers received in the
   incoming response overrides all corresponding end-to-end headers
   stored with the cache entry. The cache may add Warning headers (see
   section 14.45) to this set.

   If a header field-name in the incoming response matches more than one
   header in the cache entry, all such old headers are replaced.

     Note: this rule allows an origin server to use a 304 (Not Modified)
     response to update any header associated with a previous response
     for the same entity, although it might not always be meaningful or
     correct to do so. This rule does not allow an origin server to use
     a 304 (not Modified) response to entirely delete a header that it
     had provided with a previous response.

 


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

RFC 2068                        HTTP/1.1                    January 1997


13.5.4 Combining Byte Ranges

   A response may transfer only a subrange of the bytes of an entity-
   body, either because the request included one or more Range
   specifications, or because a connection was broken prematurely. After
   several such transfers, a cache may have received several ranges of
   the same entity-body.

   If a cache has a stored non-empty set of subranges for an entity, and
   an incoming response transfers another subrange, the cache MAY
   combine the new subrange with the existing set if both the following
   conditions are met:

     o  Both the incoming response and the cache entry must have a cache
        validator.
     o  The two cache validators must match using the strong comparison
        function (see section 13.3.3).

   If either requirement is not meant, the cache must use only the most
   recent partial response (based on the Date values transmitted with
   every response, and using the incoming response if these values are
   equal or missing), and must discard the other partial information.

13.6 Caching Negotiated Responses

   Use of server-driven content negotiation (section 12), as indicated
   by the presence of a Vary header field in a response, alters the
   conditions and procedure by which a cache can use the response for
   subsequent requests.

   A server MUST use the Vary header field (section 14.43) to inform a
   cache of what header field dimensions are used to select among
   multiple representations of a cachable response. A cache may use the
   selected representation (the entity included with that particular
   response) for replying to subsequent requests on that resource only
   when the subsequent requests have the same or equivalent values for
   all header fields specified in the Vary response-header. Requests
   with a different value for one or more of those header fields would
   be forwarded toward the origin server.

   If an entity tag was assigned to the representation, the forwarded
   request SHOULD be conditional and include the entity tags in an If-
   None-Match header field from all its cache entries for the Request-
   URI. This conveys to the server the set of entities currently held by
   the cache, so that if any one of these entities matches the requested
   entity, the server can use the ETag header in its 304 (Not Modified)
   response to tell the cache which entry is appropriate. If the
   entity-tag of the new response matches that of an existing entry, the

 

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

RFC 2068                        HTTP/1.1                    January 1997


   new response SHOULD be used to update the header fields of the
   existing entry, and the result MUST be returned to the client.

   The Vary header field may also inform the cache that the
   representation was selected using criteria not limited to the
   request-headers; in this case, a cache MUST NOT use the response in a
   reply to a subsequent request unless the cache relays the new request
   to the origin server in a conditional request and the server responds
   with 304 (Not Modified), including an entity tag or Content-Location
   that indicates which entity should be used.

   If any of the existing cache entries contains only partial content
   for the associated entity, its entity-tag SHOULD NOT be included in
   the If-None-Match header unless the request is for a range that would
   be fully satisfied by that entry.

   If a cache receives a successful response whose Content-Location
   field matches that of an existing cache entry for the same Request-
   URI, whose entity-tag differs from that of the existing entry, and
   whose Date is more recent than that of the existing entry, the
   existing entry SHOULD NOT be returned in response to future requests,
   and should be deleted from the cache.

13.7 Shared and Non-Shared Caches

   For reasons of security and privacy, it is necessary to make a
   distinction between "shared" and "non-shared" caches. A non-shared
   cache is one that is accessible only to a single user. Accessibility
   in this case SHOULD be enforced by appropriate security mechanisms.
   All other caches are considered to be "shared." Other sections of
   this specification place certain constraints on the operation of
   shared caches in order to prevent loss of privacy or failure of
   access controls.

13.8 Errors or Incomplete Response Cache Behavior

   A cache that receives an incomplete response (for example, with fewer
   bytes of data than specified in a Content-Length header) may store
   the response. However, the cache MUST treat this as a partial
   response.  Partial responses may be combined as described in section
   13.5.4; the result might be a full response or might still be
   partial. A cache MUST NOT return a partial response to a client
   without explicitly marking it as such, using the 206 (Partial
   Content) status code. A cache MUST NOT return a partial response
   using a status code of 200 (OK).

   If a cache receives a 5xx response while attempting to revalidate an
   entry, it may either forward this response to the requesting client,

 

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

RFC 2068                        HTTP/1.1                    January 1997


   or act as if the server failed to respond. In the latter case, it MAY
   return a previously received response unless the cached entry
   includes the "must-revalidate" Cache-Control directive (see section
   14.9).

13.9 Side Effects of GET and HEAD

   Unless the origin server explicitly prohibits the caching of their
   responses, the application of GET and HEAD methods to any resources
   SHOULD NOT have side effects that would lead to erroneous behavior if
   these responses are taken from a cache. They may still have side
   effects, but a cache is not required to consider such side effects in
   its caching decisions. Caches are always expected to observe an
   origin server's explicit restrictions on caching.

   We note one exception to this rule: since some applications have
   traditionally used GETs and HEADs with query URLs (those containing a
   "?" in the rel_path part) to perform operations with significant side
   effects, caches MUST NOT treat responses to such URLs as fresh unless
   the server provides an explicit expiration time. This specifically
   means that responses from HTTP/1.0 servers for such URIs should not
   be taken from a cache. See section 9.1.1 for related information.

13.10 Invalidation After Updates or Deletions

   The effect of certain methods at the origin server may cause one or
   more existing cache entries to become non-transparently invalid. That
   is, although they may continue to be "fresh," they do not accurately
   reflect what the origin server would return for a new request.

   There is no way for the HTTP protocol to guarantee that all such
   cache entries are marked invalid. For example, the request that
   caused the change at the origin server may not have gone through the
   proxy where a cache entry is stored. However, several rules help
   reduce the likelihood of erroneous behavior.

   In this section, the phrase "invalidate an entity" means that the
   cache should either remove all instances of that entity from its
   storage, or should mark these as "invalid" and in need of a mandatory
   revalidation before they can be returned in response to a subsequent
   request.

 

 

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


   Some HTTP methods may invalidate an entity. This is either the entity
   referred to by the Request-URI, or by the Location or Content-
   Location response-headers (if present). These methods are:

     o  PUT
     o  DELETE
     o  POST

   In order to prevent denial of service attacks, an invalidation based
   on the URI in a Location or Content-Location header MUST only be
   performed if the host part is the same as in the Request-URI.

13.11 Write-Through Mandatory

   All methods that may be expected to cause modifications to the origin
   server's resources MUST be written through to the origin server. This
   currently includes all methods except for GET and HEAD. A cache MUST
   NOT reply to such a request from a client before having transmitted
   the request to the inbound server, and having received a
   corresponding response from the inbound server. This does not prevent
   a cache from sending a 100 (Continue) response before the inbound
   server has replied.

   The alternative (known as "write-back" or "copy-back" caching) is not
   allowed in HTTP/1.1, due to the difficulty of providing consistent
   updates and the problems arising from server, cache, or network
   failure prior to write-back.

13.12 Cache Replacement

   If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
   response is received from a resource while any existing responses for
   the same resource are cached, the cache SHOULD use the new response
   to reply to the current request. It may insert it into cache storage
   and may, if it meets all other requirements, use it to respond to any
   future requests that would previously have caused the old response to
   be returned. If it inserts the new response into cache storage it
   should follow the rules in section 13.5.3.

     Note: a new response that has an older Date header value than
     existing cached responses is not cachable.

13.13 History Lists

   User agents often have history mechanisms, such as "Back" buttons and
   history lists, which can be used to redisplay an entity retrieved
   earlier in a session.

 


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

RFC 2068                        HTTP/1.1                    January 1997


   History mechanisms and caches are different. In particular history
   mechanisms SHOULD NOT try to show a semantically transparent view of
   the current state of a resource. Rather, a history mechanism is meant
   to show exactly what the user saw at the time when the resource was
   retrieved.

   By default, an expiration time does not apply to history mechanisms.
   If the entity is still in storage, a history mechanism should display
   it even if the entity has expired, unless the user has specifically
   configured the agent to refresh expired history documents.

   This should not be construed to prohibit the history mechanism from
   telling the user that a view may be stale.

     Note: if history list mechanisms unnecessarily prevent users from
     viewing stale resources, this will tend to force service authors to
     avoid using HTTP expiration controls and cache controls when they
     would otherwise like to. Service authors may consider it important
     that users not be presented with error messages or warning messages
     when they use navigation controls (such as BACK) to view previously
     fetched resources. Even though sometimes such resources ought not
     to cached, or ought to expire quickly, user interface
     considerations may force service authors to resort to other means
     of preventing caching (e.g. "once-only" URLs) in order not to
     suffer the effects of improperly functioning history mechanisms.

14 Header Field Definitions

   This section defines the syntax and semantics of all standard
   HTTP/1.1 header fields. For entity-header fields, both sender and
   recipient refer to either the client or the server, depending on who
   sends and who receives the entity.

 

 

 

 

 

 

 

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


14.1 Accept

   The Accept request-header field can be used to specify certain media
   types which are acceptable for the response. Accept headers can be
   used to indicate that the request is specifically limited to a small
   set of desired types, as in the case of a request for an in-line
   image.

          Accept         = "Accept" ":"
                           #( media-range [ accept-params ] )

          media-range    = ( "*/*"
                           | ( type "/" "*" )
                           | ( type "/" subtype )
                           ) *( ";" parameter )

          accept-params  = ";" "q" "=" qvalue *( accept-extension )

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

   The asterisk "*" character is used to group media types into ranges,
   with "*/*" indicating all media types and "type/*" indicating all
   subtypes of that type. The media-range MAY include media type
   parameters that are applicable to that range.

   Each media-range MAY be followed by one or more accept-params,
   beginning with the "q" parameter for indicating a relative quality
   factor. The first "q" parameter (if any) separates the media-range
   parameter(s) from the accept-params. Quality factors allow the user
   or user agent to indicate the relative degree of preference for that
   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
   default value is q=1.

     Note: Use of the "q" parameter name to separate media type
     parameters from Accept extension parameters is due to historical
     practice.  Although this prevents any media type parameter named
     "q" from being used with a media range, such an event is believed
     to be unlikely given the lack of any "q" parameters in the IANA
     media type registry and the rare usage of any media type parameters
     in Accept. Future media types should be discouraged from
     registering any parameter named "q".

   The example

          Accept: audio/*; q=0.2, audio/basic

   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
   type if it is the best available after an 80% mark-down in quality."

 

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

RFC 2068                        HTTP/1.1                    January 1997


   If no Accept header field is present, then it is assumed that the
   client accepts all media types. If an Accept header field is present,
   and if the server cannot send a response which is acceptable
   according to the combined Accept field value, then the server SHOULD
   send a 406 (not acceptable) response.

   A more elaborate example is

          Accept: text/plain; q=0.5, text/html,
                  text/x-dvi; q=0.8, text/x-c

   Verbally, this would be interpreted as "text/html and text/x-c are
   the preferred media types, but if they do not exist, then send the
   text/x-dvi entity, and if that does not exist, send the text/plain
   entity."

   Media ranges can be overridden by more specific media ranges or
   specific media types. If more than one media range applies to a given
   type, the most specific reference has precedence. For example,

          Accept: text/*, text/html, text/html;level=1, */*

   have the following precedence:

          1) text/html;level=1
          2) text/html
          3) text/*
          4) */*

   The media type quality factor associated with a given type is
   determined by finding the media range with the highest precedence
   which matches that type. For example,

          Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
                  text/html;level=2;q=0.4, */*;q=0.5

   would cause the following values to be associated:

          text/html;level=1         = 1
          text/html                 = 0.7
          text/plain                = 0.3
          image/jpeg                = 0.5
          text/html;level=2         = 0.4
          text/html;level=3         = 0.7

     Note: A user agent may be provided with a default set of quality
     values for certain media ranges. However, unless the user agent is
     a closed system which cannot interact with other rendering agents,

 

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

RFC 2068                        HTTP/1.1                    January 1997


     this default set should be configurable by the user.

14.2 Accept-Charset

   The Accept-Charset request-header field can be used to indicate what
   character sets are acceptable for the response. This field allows
   clients capable of understanding more comprehensive or special-
   purpose character sets to signal that capability to a server which is
   capable of representing documents in those character sets. The ISO-
   8859-1 character set can be assumed to be acceptable to all user
   agents.

          Accept-Charset = "Accept-Charset" ":"
                    1#( charset [ ";" "q" "=" qvalue ] )

   Character set values are described in section 3.4. Each charset may
   be given an associated quality value which represents the user's
   preference for that charset. The default value is q=1. An example is

          Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

   If no Accept-Charset header is present, the default is that any
   character set is acceptable. If an Accept-Charset header is present,
   and if the server cannot send a response which is acceptable
   according to the Accept-Charset header, then the server SHOULD send
   an error response with the 406 (not acceptable) status code, though
   the sending of an unacceptable response is also allowed.

14.3 Accept-Encoding

   The Accept-Encoding request-header field is similar to Accept, but
   restricts the content-coding values (section 14.12) which are
   acceptable in the response.

          Accept-Encoding  = "Accept-Encoding" ":"
                                    #( content-coding )

   An example of its use is

          Accept-Encoding: compress, gzip

   If no Accept-Encoding header is present in a request, the server MAY
   assume that the client will accept any content coding. If an Accept-
   Encoding header is present, and if the server cannot send a response
   which is acceptable according to the Accept-Encoding header, then the
   server SHOULD send an error response with the 406 (Not Acceptable)
   status code.

 


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

RFC 2068                        HTTP/1.1                    January 1997


   An empty Accept-Encoding value indicates none are acceptable.

14.4 Accept-Language

   The Accept-Language request-header field is similar to Accept, but
   restricts the set of natural languages that are preferred as a
   response to the request.

          Accept-Language = "Accept-Language" ":"
                            1#( language-range [ ";" "q" "=" qvalue ] )

          language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

   Each language-range MAY be given an associated quality value which
   represents an estimate of the user's preference for the languages
   specified by that range. The quality value defaults to "q=1". For
   example,

          Accept-Language: da, en-gb;q=0.8, en;q=0.7

   would mean: "I prefer Danish, but will accept British English and
   other types of English." A language-range matches a language-tag if
   it exactly equals the tag, or if it exactly equals a prefix of the
   tag such that the first tag character following the prefix is "-".
   The special range "*", if present in the Accept-Language field,
   matches every tag not matched by any other range present in the
   Accept-Language field.

     Note: This use of a prefix matching rule does not imply that
     language tags are assigned to languages in such a way that it is
     always true that if a user understands a language with a certain
     tag, then this user will also understand all languages with tags
     for which this tag is a prefix. The prefix rule simply allows the
     use of prefix tags if this is the case.

   The language quality factor assigned to a language-tag by the
   Accept-Language field is the quality value of the longest language-
   range in the field that matches the language-tag. If no language-
   range in the field matches the tag, the language quality factor
   assigned is 0. If no Accept-Language header is present in the
   request, the server SHOULD assume that all languages are equally
   acceptable. If an Accept-Language header is present, then all
   languages which are assigned a quality factor greater than 0 are
   acceptable.

   It may be contrary to the privacy expectations of the user to send an
   Accept-Language header with the complete linguistic preferences of
   the user in every request. For a discussion of this issue, see

 

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

RFC 2068                        HTTP/1.1                    January 1997


   section 15.7.

     Note: As intelligibility is highly dependent on the individual
     user, it is recommended that client applications make the choice of
     linguistic preference available to the user. If the choice is not
     made available, then the Accept-Language header field must not be
     given in the request.

14.5 Accept-Ranges

   The Accept-Ranges response-header field allows the server to indicate
   its acceptance of range requests for a resource:

          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges

          acceptable-ranges = 1#range-unit | "none"

   Origin servers that accept byte-range requests MAY send

          Accept-Ranges: bytes

   but are not required to do so. Clients MAY generate byte-range
   requests without having received this header for the resource
   involved.

   Servers that do not accept any kind of range request for a  resource
   MAY send

          Accept-Ranges: none

   to advise the client not to attempt a range request.

14.6 Age

   The Age response-header field conveys the sender's estimate of the
   amount of time since the response (or its revalidation) was generated
   at the origin server. A cached response is "fresh" if its age does
   not exceed its freshness lifetime. Age values are calculated as
   specified in section 13.2.3.

           Age = "Age" ":" age-value

           age-value = delta-seconds

   Age values are non-negative decimal integers, representing time in
   seconds.

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


   If a cache receives a value larger than the largest positive integer
   it can represent, or if any of its age calculations overflows, it
   MUST transmit an Age header with a value of 2147483648 (2^31).
   HTTP/1.1 caches MUST send an Age header in every response. Caches
   SHOULD use an arithmetic type of at least 31 bits of range.

14.7 Allow

   The Allow entity-header field lists the set of methods supported by
   the resource identified by the Request-URI. The purpose of this field
   is strictly to inform the recipient of valid methods associated with
   the resource. An Allow header field MUST be present in a 405 (Method
   Not Allowed) response.

          Allow          = "Allow" ":" 1#method

   Example of use:

          Allow: GET, HEAD, PUT

   This field cannot prevent a client from trying other methods.
   However, the indications given by the Allow header field value SHOULD
   be followed. The actual set of allowed methods is defined by the
   origin server at the time of each request.

   The Allow header field MAY be provided with a PUT request to
   recommend the methods to be supported by the new or modified
   resource. The server is not required to support these methods and
   SHOULD include an Allow header in the response giving the actual
   supported methods.

   A proxy MUST NOT modify the Allow header field even if it does not
   understand all the methods specified, since the user agent MAY have
   other means of communicating with the origin server.

   The Allow header field does not indicate what methods are implemented
   at the server level. Servers MAY use the Public response-header field
   (section 14.35) to describe what methods are implemented on the
   server as a whole.

14.8 Authorization

   A user agent that wishes to authenticate itself with a server--
   usually, but not necessarily, after receiving a 401 response--MAY do
   so by including an Authorization request-header field with the
   request. The Authorization field value consists of credentials
   containing the authentication information of the user agent for the
   realm of the resource being requested.

谁翻译了别忘了给我发一份 [email protected]


 




相关文章

相关软件