软件工程

本类阅读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---5

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

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

RFC 2068                        HTTP/1.1                    January 1997


   response is primarily intended to allow input for actions to take
   place without causing a change to the user agent's active document
   view. The response MAY include new metainformation in the form of
   entity-headers, which SHOULD apply to the document currently in the
   user agent's active view.

   The 204 response MUST NOT include a message-body, and thus is always
   terminated by the first empty line after the header fields.

10.2.6 205 Reset Content

   The server has fulfilled the request and the user agent SHOULD reset
   the document view which caused the request to be sent. This response
   is primarily intended to allow input for actions to take place via
   user input, followed by a clearing of the form in which the input is
   given so that the user can easily initiate another input action. The
   response MUST NOT include an entity.

10.2.7 206 Partial Content

   The server has fulfilled the partial GET request for the resource.
   The request must have included a Range header field (section 14.36)
   indicating the desired range. The response MUST include either a
   Content-Range header field (section 14.17) indicating the range
   included with this response, or a multipart/byteranges Content-Type
   including Content-Range fields for each part. If multipart/byteranges
   is not used, the Content-Length header field in the response MUST
   match the actual number of OCTETs transmitted in the message-body.

   A cache that does not support the Range and Content-Range headers
   MUST NOT cache 206 (Partial) responses.

10.3 Redirection 3xx

   This class of status code indicates that further action needs to be
   taken by the user agent in order to fulfill the request. The action
   required MAY be carried out by the user agent without interaction
   with the user if and only if the method used in the second request is
   GET or HEAD. A user agent SHOULD NOT automatically redirect a request
   more than 5 times, since such redirections usually indicate an
   infinite loop.

 

 

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


10.3.1 300 Multiple Choices

   The requested resource corresponds to any one of a set of
   representations, each with its own specific location, and agent-
   driven negotiation information (section 12) is being provided so that
   the user (or user agent) can select a preferred representation and
   redirect its request to that location.

   Unless it was a HEAD request, the response SHOULD include an entity
   containing a list of resource characteristics and location(s) from
   which the user or user agent can choose the one most appropriate. The
   entity format is specified by the media type given in the Content-
   Type header field. Depending upon the format and the capabilities of
   the user agent, selection of the most appropriate choice may be
   performed automatically.  However, this specification does not define
   any standard for such automatic selection.

   If the server has a preferred choice of representation, it SHOULD
   include the specific URL for that representation in the Location
   field; user agents MAY use the Location field value for automatic
   redirection.  This response is cachable unless indicated otherwise.

10.3.2 301 Moved Permanently

   The requested resource has been assigned a new permanent URI and any
   future references to this resource SHOULD be done using one of the
   returned URIs. Clients with link editing capabilities SHOULD
   automatically re-link references to the Request-URI to one or more of
   the new references returned by the server, where possible. This
   response is cachable unless indicated otherwise.

   If the new URI is a location, its URL SHOULD be given by the Location
   field in the response. Unless the request method was HEAD, the entity
   of the response SHOULD contain a short hypertext note with a
   hyperlink to the new URI(s).

   If the 301 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

     Note: When automatically redirecting a POST request after receiving
     a 301 status code, some existing HTTP/1.0 user agents will
     erroneously change it into a GET request.

 

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


10.3.3 302 Moved Temporarily

   The requested resource resides temporarily under a different URI.
   Since the redirection may be altered on occasion, the client SHOULD
   continue to use the Request-URI for future requests. This response is
   only cachable if indicated by a Cache-Control or Expires header
   field.

   If the new URI is a location, its URL SHOULD be given by the Location
   field in the response. Unless the request method was HEAD, the entity
   of the response SHOULD contain a short hypertext note with a
   hyperlink to the new URI(s).

   If the 302 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

     Note: When automatically redirecting a POST request after receiving
     a 302 status code, some existing HTTP/1.0 user agents will
     erroneously change it into a GET request.

10.3.4 303 See Other

   The response to the request can be found under a different URI and
   SHOULD be retrieved using a GET method on that resource. This method
   exists primarily to allow the output of a POST-activated script to
   redirect the user agent to a selected resource. The new URI is not a
   substitute reference for the originally requested resource. The 303
   response is not cachable, but the response to the second (redirected)
   request MAY be cachable.

   If the new URI is a location, its URL SHOULD be given by the Location
   field in the response. Unless the request method was HEAD, the entity
   of the response SHOULD contain a short hypertext note with a
   hyperlink to the new URI(s).

10.3.5 304 Not Modified

   If the client has performed a conditional GET request and access is
   allowed, but the document has not been modified, the server SHOULD
   respond with this status code. The response MUST NOT contain a
   message-body.

 

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


   The response MUST include the following header fields:

  o  Date

  o  ETag and/or Content-Location, if the header would have been sent in
     a 200 response to the same request

  o  Expires, Cache-Control, and/or Vary, if the field-value might
     differ from that sent in any previous response for the same variant

   If the conditional GET used a strong cache validator (see section
   13.3.3), the response SHOULD NOT include other entity-headers.
   Otherwise (i.e., the conditional GET used a weak validator), the
   response MUST NOT include other entity-headers; this prevents
   inconsistencies between cached entity-bodies and updated headers.

   If a 304 response indicates an entity not currently cached, then the
   cache MUST disregard the response and repeat the request without the
   conditional.

   If a cache uses a received 304 response to update a cache entry, the
   cache MUST update the entry to reflect any new field values given in
   the response.

   The 304 response MUST NOT include a message-body, and thus is always
   terminated by the first empty line after the header fields.

10.3.6 305 Use Proxy

   The requested resource MUST be accessed through the proxy given by
   the Location field. The Location field gives the URL of the proxy.
   The recipient is expected to repeat the request via the proxy.

10.4 Client Error 4xx

   The 4xx class of status code is intended for cases in which the
   client seems to have erred. Except when responding to a HEAD request,
   the server SHOULD include an entity containing an explanation of the
   error situation, and whether it is a temporary or permanent
   condition. These status codes are applicable to any request method.
   User agents SHOULD display any included entity to the user.

     Note: If the client is sending data, a server implementation using
     TCP should be careful to ensure that the client acknowledges
     receipt of the packet(s) containing the response, before the server
     closes the input connection. If the client continues sending data
     to the server after the close, the server's TCP stack will send a
     reset packet to the client, which may erase the client's

 

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

RFC 2068                        HTTP/1.1                    January 1997


     unacknowledged input buffers before they can be read and
     interpreted by the HTTP application.

10.4.1 400 Bad Request

   The request could not be understood by the server due to malformed
   syntax. The client SHOULD NOT repeat the request without
   modifications.

10.4.2 401 Unauthorized

   The request requires user authentication. The response MUST include a
   WWW-Authenticate header field (section 14.46) containing a challenge
   applicable to the requested resource. The client MAY repeat the
   request with a suitable Authorization header field (section 14.8). If
   the request already included Authorization credentials, then the 401
   response indicates that authorization has been refused for those
   credentials. If the 401 response contains the same challenge as the
   prior response, and the user agent has already attempted
   authentication at least once, then the user SHOULD be presented the
   entity that was given in the response, since that entity MAY include
   relevant diagnostic information. HTTP access authentication is
   explained in section 11.

10.4.3 402 Payment Required

   This code is reserved for future use.

10.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help and the request SHOULD NOT be repeated.
   If the request method was not HEAD and the server wishes to make
   public why the request has not been fulfilled, it SHOULD describe the
   reason for the refusal in the entity. This status code is commonly
   used when the server does not wish to reveal exactly why the request
   has been refused, or when no other response is applicable.

10.4.5 404 Not Found

   The server has not found anything matching the Request-URI. No
   indication is given of whether the condition is temporary or
   permanent.

 

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


   If the server does not wish to make this information available to the
   client, the status code 403 (Forbidden) can be used instead. The 410
   (Gone) status code SHOULD be used if the server knows, through some
   internally configurable mechanism, that an old resource is
   permanently unavailable and has no forwarding address.

10.4.6 405 Method Not Allowed

   The method specified in the Request-Line is not allowed for the
   resource identified by the Request-URI. The response MUST include an
   Allow header containing a list of valid methods for the requested
   resource.

10.4.7 406 Not Acceptable

   The resource identified by the request is only capable of generating
   response entities which have content characteristics not acceptable
   according to the accept headers sent in the request.

   Unless it was a HEAD request, the response SHOULD include an entity
   containing a list of available entity characteristics and location(s)
   from which the user or user agent can choose the one most
   appropriate.  The entity format is specified by the media type given
   in the Content-Type header field. Depending upon the format and the
   capabilities of the user agent, selection of the most appropriate
   choice may be performed automatically. However, this specification
   does not define any standard for such automatic selection.

     Note: HTTP/1.1 servers are allowed to return responses which are
     not acceptable according to the accept headers sent in the request.
     In some cases, this may even be preferable to sending a 406
     response. User agents are encouraged to inspect the headers of an
     incoming response to determine if it is acceptable. If the response
     could be unacceptable, a user agent SHOULD temporarily stop receipt
     of more data and query the user for a decision on further actions.

10.4.8 407 Proxy Authentication Required

   This code is similar to 401 (Unauthorized), but indicates that the
   client MUST first authenticate itself with the proxy. The proxy MUST
   return a Proxy-Authenticate header field (section 14.33) containing a
   challenge applicable to the proxy for the requested resource. The
   client MAY repeat the request with a suitable Proxy-Authorization
   header field (section 14.34). HTTP access authentication is explained
   in section 11.

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


10.4.9 408 Request Timeout

   The client did not produce a request within the time that the server
   was prepared to wait. The client MAY repeat the request without
   modifications at any later time.

10.4.10 409 Conflict

   The request could not be completed due to a conflict with the current
   state of the resource. This code is only allowed in situations where
   it is expected that the user might be able to resolve the conflict
   and resubmit the request. The response body SHOULD include enough
   information for the user to recognize the source of the conflict.
   Ideally, the response entity would include enough information for the
   user or user agent to fix the problem; however, that may not be
   possible and is not required.

   Conflicts are most likely to occur in response to a PUT request. If
   versioning is being used and the entity being PUT includes changes to
   a resource which conflict with those made by an earlier (third-party)
   request, the server MAY use the 409 response to indicate that it
   can't complete the request. In this case, the response entity SHOULD
   contain a list of the differences between the two versions in a
   format defined by the response Content-Type.

10.4.11 410 Gone

   The requested resource is no longer available at the server and no
   forwarding address is known. This condition SHOULD be considered
   permanent. Clients with link editing capabilities SHOULD delete
   references to the Request-URI after user approval. If the server does
   not know, or has no facility to determine, whether or not the
   condition is permanent, the status code 404 (Not Found) SHOULD be
   used instead.  This response is cachable unless indicated otherwise.

   The 410 response is primarily intended to assist the task of web
   maintenance by notifying the recipient that the resource is
   intentionally unavailable and that the server owners desire that
   remote links to that resource be removed. Such an event is common for
   limited-time, promotional services and for resources belonging to
   individuals no longer working at the server's site. It is not
   necessary to mark all permanently unavailable resources as "gone" or
   to keep the mark for any length of time -- that is left to the
   discretion of the server owner.

 

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


10.4.12 411 Length Required

   The server refuses to accept the request without a defined Content-
   Length. The client MAY repeat the request if it adds a valid
   Content-Length header field containing the length of the message-body
   in the request message.

10.4.13 412 Precondition Failed

   The precondition given in one or more of the request-header fields
   evaluated to false when it was tested on the server. This response
   code allows the client to place preconditions on the current resource
   metainformation (header field data) and thus prevent the requested
   method from being applied to a resource other than the one intended.

10.4.14 413 Request Entity Too Large

   The server is refusing to process a request because the request
   entity is larger than the server is willing or able to process. The
   server may close the connection to prevent the client from continuing
   the request.

   If the condition is temporary, the server SHOULD include a Retry-
   After header field to indicate that it is temporary and after what
   time the client may try again.

10.4.15 414 Request-URI Too Long

   The server is refusing to service the request because the Request-URI
   is longer than the server is willing to interpret. This rare
   condition is only likely to occur when a client has improperly
   converted a POST request to a GET request with long query
   information, when the client has descended into a URL "black hole" of
   redirection (e.g., a redirected URL prefix that points to a suffix of
   itself), or when the server is under attack by a client attempting to
   exploit security holes present in some servers using fixed-length
   buffers for reading or manipulating the Request-URI.

10.4.16 415 Unsupported Media Type

   The server is refusing to service the request because the entity of
   the request is in a format not supported by the requested resource
   for the requested method.

 

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


10.5 Server Error 5xx

   Response status codes beginning with the digit "5" indicate cases in
   which the server is aware that it has erred or is incapable of
   performing the request. Except when responding to a HEAD request, the
   server SHOULD include an entity containing an explanation of the
   error situation, and whether it is a temporary or permanent
   condition. User agents SHOULD display any included entity to the
   user. These response codes are applicable to any request method.

10.5.1 500 Internal Server Error

   The server encountered an unexpected condition which prevented it
   from fulfilling the request.

10.5.2 501 Not Implemented

   The server does not support the functionality required to fulfill the
   request. This is the appropriate response when the server does not
   recognize the request method and is not capable of supporting it for
   any resource.

10.5.3 502 Bad Gateway

   The server, while acting as a gateway or proxy, received an invalid
   response from the upstream server it accessed in attempting to
   fulfill the request.

10.5.4 503 Service Unavailable

   The server is currently unable to handle the request due to a
   temporary overloading or maintenance of the server. The implication
   is that this is a temporary condition which will be alleviated after
   some delay. If known, the length of the delay may be indicated in a
   Retry-After header.  If no Retry-After is given, the client SHOULD
   handle the response as it would for a 500 response.

     Note: The existence of the 503 status code does not imply that a
     server must use it when becoming overloaded. Some servers may wish
     to simply refuse the connection.

10.5.5 504 Gateway Timeout

   The server, while acting as a gateway or proxy, did not receive a
   timely response from the upstream server it accessed in attempting to
   complete the request.

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


10.5.6 505 HTTP Version Not Supported

   The server does not support, or refuses to support, the HTTP protocol
   version that was used in the request message. The server is
   indicating that it is unable or unwilling to complete the request
   using the same major version as the client, as described in section
   3.1, other than with this error message. The response SHOULD contain
   an entity describing why that version is not supported and what other
   protocols are supported by that server.

11 Access Authentication

   HTTP provides a simple challenge-response authentication mechanism
   which MAY be used by a server to challenge a client request and by a
   client to provide authentication information. It uses an extensible,
   case-insensitive token to identify the authentication scheme,
   followed by a comma-separated list of attribute-value pairs which
   carry the parameters necessary for achieving authentication via that
   scheme.

          auth-scheme    = token

          auth-param     = token "=" quoted-string

   The 401 (Unauthorized) response message is used by an origin server
   to challenge the authorization of a user agent. This response MUST
   include a WWW-Authenticate header field containing at least one
   challenge applicable to the requested resource.

          challenge      = auth-scheme 1*SP realm *( "," auth-param )

          realm          = "realm" "=" realm-value
          realm-value    = quoted-string

   The realm attribute (case-insensitive) is required for all
   authentication schemes which issue a challenge. The realm value
   (case-sensitive), in combination with the canonical root URL (see
   section 5.1.2) of the server being accessed, defines the protection
   space. These realms allow the protected resources on a server to be
   partitioned into a set of protection spaces, each with its own
   authentication scheme and/or authorization database. The realm value
   is a string, generally assigned by the origin server, which may have
   additional semantics specific to the authentication scheme.

   A user agent that wishes to authenticate itself with a server--
   usually, but not necessarily, after receiving a 401 or 411 response-
   -MAY do so by including an Authorization header field with the
   request. The Authorization field value consists of credentials

 

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

RFC 2068                        HTTP/1.1                    January 1997


   containing the authentication information of the user agent for the
   realm of the resource being requested.

          credentials    = basic-credentials
                         | auth-scheme #auth-param

   The domain over which credentials can be automatically applied by a
   user agent is determined by the protection space. If a prior request
   has been authorized, the same credentials MAY be reused for all other
   requests within that protection space for a period of time determined
   by the authentication scheme, parameters, and/or user preference.
   Unless otherwise defined by the authentication scheme, a single
   protection space cannot extend outside the scope of its server.

   If the server does not wish to accept the credentials sent with a
   request, it SHOULD return a 401 (Unauthorized) response. The response
   MUST include a WWW-Authenticate header field containing the (possibly
   new) challenge applicable to the requested resource and an entity
   explaining the refusal.

   The HTTP protocol does not restrict applications to this simple
   challenge-response mechanism for access authentication. Additional
   mechanisms MAY be used, such as encryption at the transport level or
   via message encapsulation, and with additional header fields
   specifying authentication information. However, these additional
   mechanisms are not defined by this specification.

   Proxies MUST be completely transparent regarding user agent
   authentication. That is, they MUST forward the WWW-Authenticate and
   Authorization headers untouched, and follow the rules found in
   section 14.8.

   HTTP/1.1 allows a client to pass authentication information to and
   from a proxy via the Proxy-Authenticate and Proxy-Authorization
   headers.

11.1 Basic Authentication Scheme

   The "basic" authentication scheme is based on the model that the user
   agent must authenticate itself with a user-ID and a password for each
   realm. The realm value should be considered an opaque string which
   can only be compared for equality with other realms on that server.
   The server will service the request only if it can validate the
   user-ID and password for the protection space of the Request-URI.
   There are no optional authentication parameters.

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


   Upon receipt of an unauthorized request for a URI within the
   protection space, the server MAY respond with a challenge like the
   following:

          WWW-Authenticate: Basic realm="WallyWorld"

   where "WallyWorld" is the string assigned by the server to identify
   the protection space of the Request-URI.

   To receive authorization, the client sends the userid and password,
   separated by a single colon (":") character, within a base64  encoded
   string in the credentials.

          basic-credentials = "Basic" SP basic-cookie

          basic-cookie   = <base64 [7] encoding of user-pass,
                           except not limited to 76 char/line>

          user-pass   = userid ":" password

          userid      = *<TEXT excluding ":">

          password    = *TEXT

   Userids might be case sensitive.

   If the user agent wishes to send the userid "Aladdin" and password
   "open sesame", it would use the following header field:

          Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

   See section 15 for security considerations associated with Basic
   authentication.

11.2 Digest Authentication Scheme

   A digest authentication for HTTP is specified in RFC 2069 [32].

12 Content Negotiation

   Most HTTP responses include an entity which contains information for
   interpretation by a human user. Naturally, it is desirable to supply
   the user with the "best available" entity corresponding to the
   request.  Unfortunately for servers and caches, not all users have
   the same preferences for what is "best," and not all user agents are
   equally capable of rendering all entity types. For that reason, HTTP
   has provisions for several mechanisms for "content negotiation" --
   the process of selecting the best representation for a given response

 

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

RFC 2068                        HTTP/1.1                    January 1997


   when there are multiple representations available.

     Note: This is not called "format negotiation" because the alternate
     representations may be of the same media type, but use different
     capabilities of that type, be in different languages, etc.

   Any response containing an entity-body MAY be subject to negotiation,
   including error responses.

   There are two kinds of content negotiation which are possible in
   HTTP: server-driven and agent-driven negotiation. These two kinds of
   negotiation are orthogonal and thus may be used separately or in
   combination. One method of combination, referred to as transparent
   negotiation, occurs when a cache uses the agent-driven negotiation
   information provided by the origin server in order to provide
   server-driven negotiation for subsequent requests.

12.1 Server-driven Negotiation

   If the selection of the best representation for a response is made by
   an algorithm located at the server, it is called server-driven
   negotiation.  Selection is based on the available representations of
   the response (the dimensions over which it can vary; e.g. language,
   content-coding, etc.) and the contents of particular header fields in
   the request message or on other information pertaining to the request
   (such as the network address of the client).

   Server-driven negotiation is advantageous when the algorithm for
   selecting from among the available representations is difficult to
   describe to the user agent, or when the server desires to send its
   "best guess" to the client along with the first response (hoping to
   avoid the round-trip delay of a subsequent request if the "best
   guess" is good enough for the user). In order to improve the server's
   guess, the user agent MAY include request header fields (Accept,
   Accept-Language, Accept-Encoding, etc.) which describe its
   preferences for such a response.

   Server-driven negotiation has disadvantages:

1. It is impossible for the server to accurately determine what might be
  "best" for any given user, since that would require complete
  knowledge of both the capabilities of the user agent and the intended
  use for the response (e.g., does the user want to view it on screen
  or print it on paper?).

2. Having the user agent describe its capabilities in every request can
  be both very inefficient (given that only a small percentage of
  responses have multiple representations) and a potential violation of

 

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

RFC 2068                        HTTP/1.1                    January 1997


  the user's privacy.

3. It complicates the implementation of an origin server and the
  algorithms for generating responses to a request.

4. It may limit a public cache's ability to use the same response for
  multiple user's requests.

   HTTP/1.1 includes the following request-header fields for enabling
   server-driven negotiation through description of user agent
   capabilities and user preferences: Accept (section 14.1), Accept-
   Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
   Language (section 14.4), and User-Agent (section 14.42). However, an
   origin server is not limited to these dimensions and MAY vary the
   response based on any aspect of the request, including information
   outside the request-header fields or within extension header fields
   not defined by this specification.

   HTTP/1.1 origin servers MUST include an appropriate Vary header field
   (section 14.43) in any cachable response based on server-driven
   negotiation. The Vary header field describes the dimensions over
   which the response might vary (i.e. the dimensions over which the
   origin server picks its "best guess" response from multiple
   representations).

   HTTP/1.1 public caches MUST recognize the Vary header field when it
   is included in a response and obey the requirements described in
   section 13.6 that describes the interactions between caching and
   content negotiation.

12.2 Agent-driven Negotiation

   With agent-driven negotiation, selection of the best representation
   for a response is performed by the user agent after receiving an
   initial response from the origin server. Selection is based on a list
   of the available representations of the response included within the
   header fields (this specification reserves the field-name Alternates,
   as described in appendix 19.6.2.1) or entity-body of the initial
   response, with each representation identified by its own URI.
   Selection from among the representations may be performed
   automatically (if the user agent is capable of doing so) or manually
   by the user selecting from a generated (possibly hypertext) menu.

   Agent-driven negotiation is advantageous when the response would vary
   over commonly-used dimensions (such as type, language, or encoding),
   when the origin server is unable to determine a user agent's
   capabilities from examining the request, and generally when public
   caches are used to distribute server load and reduce network usage.

 

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

RFC 2068                        HTTP/1.1                    January 1997


   Agent-driven negotiation suffers from the disadvantage of needing a
   second request to obtain the best alternate representation. This
   second request is only efficient when caching is used. In addition,
   this specification does not define any mechanism for supporting
   automatic selection, though it also does not prevent any such
   mechanism from being developed as an extension and used within
   HTTP/1.1.

   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
   status codes for enabling agent-driven negotiation when the server is
   unwilling or unable to provide a varying response using server-driven
   negotiation.

12.3 Transparent Negotiation

   Transparent negotiation is a combination of both server-driven and
   agent-driven negotiation. When a cache is supplied with a form of the
   list of available representations of the response (as in agent-driven
   negotiation) and the dimensions of variance are completely understood
   by the cache, then the cache becomes capable of performing server-
   driven negotiation on behalf of the origin server for subsequent
   requests on that resource.

   Transparent negotiation has the advantage of distributing the
   negotiation work that would otherwise be required of the origin
   server and also removing the second request delay of agent-driven
   negotiation when the cache is able to correctly guess the right
   response.

   This specification does not define any mechanism for transparent
   negotiation, though it also does not prevent any such mechanism from
   being developed as an extension and used within HTTP/1.1. An HTTP/1.1
   cache performing transparent negotiation MUST include a Vary header
   field in the response (defining the dimensions of its variance) if it
   is cachable to ensure correct interoperation with all HTTP/1.1
   clients. The agent-driven negotiation information supplied by the
   origin server SHOULD be included with the transparently negotiated
   response.

13 Caching in HTTP

   HTTP is typically used for distributed information systems, where
   performance can be improved by the use of response caches. The
   HTTP/1.1 protocol includes a number of elements intended to make
   caching work as well as possible. Because these elements are
   inextricable from other aspects of the protocol, and because they
   interact with each other, it is useful to describe the basic caching
   design of HTTP separately from the detailed descriptions of methods,

 

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

RFC 2068                        HTTP/1.1                    January 1997


   headers, response codes, etc.

   Caching would be useless if it did not significantly improve
   performance. The goal of caching in HTTP/1.1 is to eliminate the need
   to send requests in many cases, and to eliminate the need to send
   full responses in many other cases. The former reduces the number of
   network round-trips required for many operations; we use an
   "expiration" mechanism for this purpose (see section 13.2). The
   latter reduces network bandwidth requirements; we use a "validation"
   mechanism for this purpose (see section 13.3).

   Requirements for performance, availability, and disconnected
   operation require us to be able to relax the goal of semantic
   transparency. The HTTP/1.1 protocol allows origin servers, caches,
   and clients to explicitly reduce transparency when necessary.
   However, because non-transparent operation may confuse non-expert
   users, and may be incompatible with certain server applications (such
   as those for ordering merchandise), the protocol requires that
   transparency be relaxed

  o  only by an explicit protocol-level request when relaxed by client
     or origin server

  o  only with an explicit warning to the end user when relaxed by cache
     or client

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

 




相关文章

相关软件