软件工程

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

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

 


RFC 2068                        HTTP/1.1                    January 1997


   Any HTTP/1.1 message containing an entity-body SHOULD include a
   Content-Type header field defining the media type of that body. If
   and only if the media type is not given by a Content-Type field, the
   recipient MAY attempt to guess the media type via inspection of its
   content and/or the name extension(s) of the URL used to identify the
   resource. If the media type remains unknown, the recipient SHOULD
   treat it as type "application/octet-stream".

7.2.2 Length

   The length of an entity-body is the length of the message-body after
   any transfer codings have been removed. Section 4.4 defines how the
   length of a message-body is determined.

8 Connections

8.1 Persistent Connections

8.1.1 Purpose

   Prior to persistent connections, a separate TCP connection was
   established to fetch each URL, increasing the load on HTTP servers
   and causing congestion on the Internet. The use of inline images and
   other associated data often requires a client to make multiple
   requests of the same server in a short amount of time. Analyses of
   these performance problems are available [30][27]; analysis and
   results from a prototype implementation are in [26].

   Persistent HTTP connections have a number of advantages:

     o  By opening and closing fewer TCP connections, CPU time is saved,
        and memory used for TCP protocol control blocks is also saved.
     o  HTTP requests and responses can be pipelined on a connection.
        Pipelining allows a client to make multiple requests without
        waiting for each response, allowing a single TCP connection to be
        used much more efficiently, with much lower elapsed time.
     o  Network congestion is reduced by reducing the number of packets
        caused by TCP opens, and by allowing TCP sufficient time to
        determine the congestion state of the network.
     o  HTTP can evolve more gracefully; since errors can be reported
        without the penalty of closing the TCP connection. Clients using
        future versions of HTTP might optimistically try a new feature, but
        if communicating with an older server, retry with old semantics
        after an error is reported.

   HTTP implementations SHOULD implement persistent connections.

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


8.1.2 Overall Operation

   A significant difference between HTTP/1.1 and earlier versions of
   HTTP is that persistent connections are the default behavior of any
   HTTP connection. That is, unless otherwise indicated, the client may
   assume that the server will maintain a persistent connection.

   Persistent connections provide a mechanism by which a client and a
   server can signal the close of a TCP connection. This signaling takes
   place using the Connection header field. Once a close has been
   signaled, the client MUST not send any more requests on that
   connection.

8.1.2.1 Negotiation

   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
   maintain a persistent connection unless a Connection header including
   the connection-token "close" was sent in the request. If the server
   chooses to close the connection immediately after sending the
   response, it SHOULD send a Connection header including the
   connection-token close.

   An HTTP/1.1 client MAY expect a connection to remain open, but would
   decide to keep it open based on whether the response from a server
   contains a Connection header with the connection-token close. In case
   the client does not want to maintain a connection for more than that
   request, it SHOULD send a Connection header including the
   connection-token close.

   If either the client or the server sends the close token in the
   Connection header, that request becomes the last one for the
   connection.

   Clients and servers SHOULD NOT assume that a persistent connection is
   maintained for HTTP versions less than 1.1 unless it is explicitly
   signaled. See section 19.7.1 for more information on backwards
   compatibility with HTTP/1.0 clients.

   In order to remain persistent, all messages on the connection must
   have a self-defined message length (i.e., one not defined by closure
   of the connection), as described in section 4.4.

8.1.2.2 Pipelining

   A client that supports persistent connections MAY "pipeline" its
   requests (i.e., send multiple requests without waiting for each
   response). A server MUST send its responses to those requests in the
   same order that the requests were received.

 

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

RFC 2068                        HTTP/1.1                    January 1997


   Clients which assume persistent connections and pipeline immediately
   after connection establishment SHOULD be prepared to retry their
   connection if the first pipelined attempt fails. If a client does
   such a retry, it MUST NOT pipeline before it knows the connection is
   persistent. Clients MUST also be prepared to resend their requests if
   the server closes the connection before sending all of the
   corresponding responses.

8.1.3 Proxy Servers

   It is especially important that proxies correctly implement the
   properties of the Connection header field as specified in 14.2.1.

   The proxy server MUST signal persistent connections separately with
   its clients and the origin servers (or other proxy servers) that it
   connects to. Each persistent connection applies to only one transport
   link.

   A proxy server MUST NOT establish a persistent connection with an
   HTTP/1.0 client.

8.1.4 Practical Considerations

   Servers will usually have some time-out value beyond which they will
   no longer maintain an inactive connection. Proxy servers might make
   this a higher value since it is likely that the client will be making
   more connections through the same server. The use of persistent
   connections places no requirements on the length of this time-out for
   either the client or the server.

   When a client or server wishes to time-out it SHOULD issue a graceful
   close on the transport connection. Clients and servers SHOULD both
   constantly watch for the other side of the transport close, and
   respond to it as appropriate. If a client or server does not detect
   the other side's close promptly it could cause unnecessary resource
   drain on the network.

   A client, server, or proxy MAY close the transport connection at any
   time. For example, a client MAY have started to send a new request at
   the same time that the server has decided to close the "idle"
   connection. From the server's point of view, the connection is being
   closed while it was idle, but from the client's point of view, a
   request is in progress.

   This means that clients, servers, and proxies MUST be able to recover
   from asynchronous close events. Client software SHOULD reopen the
   transport connection and retransmit the aborted request without user
   interaction so long as the request method is idempotent (see section

 

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

RFC 2068                        HTTP/1.1                    January 1997


   9.1.2); other methods MUST NOT be automatically retried, although
   user agents MAY offer a human operator the choice of retrying the
   request.

   However, this automatic retry SHOULD NOT be repeated if the second
   request fails.

   Servers SHOULD always respond to at least one request per connection,
   if at all possible. Servers SHOULD NOT close a connection in the
   middle of transmitting a response, unless a network or client failure
   is suspected.

   Clients that use persistent connections SHOULD limit the number of
   simultaneous connections that they maintain to a given server. A
   single-user client SHOULD maintain AT MOST 2 connections with any
   server or proxy. A proxy SHOULD use up to 2*N connections to another
   server or proxy, where N is the number of simultaneously active
   users. These guidelines are intended to improve HTTP response times
   and avoid congestion of the Internet or other networks.

8.2 Message Transmission Requirements

General requirements:

o  HTTP/1.1 servers SHOULD maintain persistent connections and use
   TCP's flow control mechanisms to resolve temporary overloads,
   rather than terminating connections with the expectation that
   clients will retry. The latter technique can exacerbate network
   congestion.

o  An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
   the network connection for an error status while it is transmitting
   the request. If the client sees an error status, it SHOULD
   immediately cease transmitting the body. If the body is being sent
   using a "chunked" encoding (section 3.6), a zero length chunk and
   empty footer MAY be used to prematurely mark the end of the
   message. If the body was preceded by a Content-Length header, the
   client MUST close the connection.

o  An HTTP/1.1 (or later) client MUST be prepared to accept a 100
   (Continue) status followed by a regular response.

o  An HTTP/1.1 (or later) server that receives a request from a
   HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue)
   response; it SHOULD either wait for the request to be completed
   normally (thus avoiding an interrupted request) or close the
   connection prematurely.

 


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

RFC 2068                        HTTP/1.1                    January 1997


   Upon receiving a method subject to these requirements from an
   HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either
   respond with 100 (Continue) status and continue to read from the
   input stream, or respond with an error status. If it responds with an
   error status, it MAY close the transport (TCP) connection or it MAY
   continue to read and discard the rest of the request. It MUST NOT
   perform the requested method if it returns an error status.

   Clients SHOULD remember the version number of at least the most
   recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or
   later response from the server, and it sees the connection close
   before receiving any status from the server, the client SHOULD retry
   the request without user interaction so long as the request method is
   idempotent (see section 9.1.2); other methods MUST NOT be
   automatically retried, although user agents MAY offer a human
   operator the choice of retrying the request.. If the client does
   retry the request, the client

     o  MUST first send the request header fields, and then

     o  MUST wait for the server to respond with either a 100 (Continue)
        response, in which case the client should continue, or with an
        error status.

   If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from
   the server, it should assume that the server implements HTTP/1.0 or
   older and will not use the 100 (Continue) response. If in this case
   the client sees the connection close before receiving any status from
   the server, the client SHOULD retry the request. If the client does
   retry the request to this HTTP/1.0 server, it should use the
   following "binary exponential backoff" algorithm to be assured of
   obtaining a reliable response:

  1. Initiate a new connection to the server

  2. Transmit the request-headers

  3. Initialize a variable R to the estimated round-trip time to the
     server (e.g., based on the time it took to establish the
     connection), or to a constant value of 5 seconds if the round-trip
     time is not available.

  4. Compute T = R * (2**N), where N is the number of previous retries
     of this request.

  5. Wait either for an error response from the server, or for T seconds
     (whichever comes first)

 


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

RFC 2068                        HTTP/1.1                    January 1997


  6. If no error response is received, after T seconds transmit the body
     of the request.

  7. If client sees that the connection is closed prematurely, repeat
     from step 1 until the request is accepted, an error response is
     received, or the user becomes impatient and terminates the retry
     process.

   No matter what the server version, if an error status is received,
   the client

  o  MUST NOT continue and

  o  MUST close the connection if it has not completed sending the
     message.

   An HTTP/1.1 (or later) client that sees the connection close after
   receiving a 100 (Continue) but before receiving any other status
   SHOULD retry the request, and need not wait for 100 (Continue)
   response (but MAY do so if this simplifies the implementation).

9 Method Definitions

   The set of common methods for HTTP/1.1 is defined below. Although
   this set can be expanded, additional methods cannot be assumed to
   share the same semantics for separately extended clients and servers.

   The Host request-header field (section 14.23) MUST accompany all
   HTTP/1.1 requests.

9.1 Safe and Idempotent Methods

9.1.1 Safe Methods

   Implementers should be aware that the software represents the user in
   their interactions over the Internet, and should be careful to allow
   the user to be aware of any actions they may take which may have an
   unexpected significance to themselves or others.

   In particular, the convention has been established that the GET and
   HEAD methods should never have the significance of taking an action
   other than retrieval. These methods should be considered "safe." This
   allows user agents to represent other methods, such as POST, PUT and
   DELETE, in a special way, so that the user is made aware of the fact
   that a possibly unsafe action is being requested.

   Naturally, it is not possible to ensure that the server does not
   generate side-effects as a result of performing a GET request; in

 

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

RFC 2068                        HTTP/1.1                    January 1997


   fact, some dynamic resources consider that a feature. The important
   distinction here is that the user did not request the side-effects,
   so therefore cannot be held accountable for them.

9.1.2 Idempotent Methods

   Methods may also have the property of "idempotence" in that (aside
   from error or expiration issues) the side-effects of  N > 0 identical
   requests is the same as for a single request. The methods GET, HEAD,
   PUT and DELETE share this property.

9.2 OPTIONS

   The OPTIONS method represents a request for information about the
   communication options available on the request/response chain
   identified by the Request-URI. This method allows the client to
   determine the options and/or requirements associated with a resource,
   or the capabilities of a server, without implying a resource action
   or initiating a resource retrieval.

   Unless the server's response is an error, the response MUST NOT
   include entity information other than what can be considered as
   communication options (e.g., Allow is appropriate, but Content-Type
   is not). Responses to this method are not cachable.

   If the Request-URI is an asterisk ("*"), the OPTIONS request is
   intended to apply to the server as a whole. A 200 response SHOULD
   include any header fields which indicate optional features
   implemented by the server (e.g., Public), including any extensions
   not defined by this specification, in addition to any applicable
   general or response-header fields. As described in section 5.1.2, an
   "OPTIONS *" request can be applied through a proxy by specifying the
   destination server in the Request-URI without any path information.

   If the Request-URI is not an asterisk, the OPTIONS request applies
   only to the options that are available when communicating with that
   resource.  A 200 response SHOULD include any header fields which
   indicate optional features implemented by the server and applicable
   to that resource (e.g., Allow), including any extensions not defined
   by this specification, in addition to any applicable general or
   response-header fields. If the OPTIONS request passes through a
   proxy, the proxy MUST edit the response to exclude those options
   which apply to a proxy's capabilities and which are known to be
   unavailable through that proxy.

 

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


9.3 GET

   The GET method means retrieve whatever information (in the form of an
   entity) is identified by the Request-URI. If the Request-URI refers
   to a data-producing process, it is the produced data which shall be
   returned as the entity in the response and not the source text of the
   process, unless that text happens to be the output of the process.

   The semantics of the GET method change to a "conditional GET" if the
   request message includes an If-Modified-Since, If-Unmodified-Since,
   If-Match, If-None-Match, or If-Range header field. A conditional GET
   method requests that the entity be transferred only under the
   circumstances described by the conditional header field(s). The
   conditional GET method is intended to reduce unnecessary network
   usage by allowing cached entities to be refreshed without requiring
   multiple requests or transferring data already held by the client.

   The semantics of the GET method change to a "partial GET" if the
   request message includes a Range header field. A partial GET requests
   that only part of the entity be transferred, as described in section
   14.36. The partial GET method is intended to reduce unnecessary
   network usage by allowing partially-retrieved entities to be
   completed without transferring data already held by the client.

   The response to a GET request is cachable if and only if it meets the
   requirements for HTTP caching described in section 13.

9.4 HEAD

   The HEAD method is identical to GET except that the server MUST NOT
   return a message-body in the response. The metainformation contained
   in the HTTP headers in response to a HEAD request SHOULD be identical
   to the information sent in response to a GET request. This method can
   be used for obtaining metainformation about the entity implied by the
   request without transferring the entity-body itself. This method is
   often used for testing hypertext links for validity, accessibility,
   and recent modification.

   The response to a HEAD request may be cachable in the sense that the
   information contained in the response may be used to update a
   previously cached entity from that resource. If the new field values
   indicate that the cached entity differs from the current entity (as
   would be indicated by a change in Content-Length, Content-MD5, ETag
   or Last-Modified), then the cache MUST treat the cache entry as
   stale.

 

 


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

RFC 2068                        HTTP/1.1                    January 1997


9.5 POST

   The POST method is used to request that the destination server accept
   the entity enclosed in the request as a new subordinate of the
   resource identified by the Request-URI in the Request-Line. POST is
   designed to allow a uniform method to cover the following functions:

     o  Annotation of existing resources;

     o  Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

     o  Providing a block of data, such as the result of submitting a
        form, to a data-handling process;

     o  Extending a database through an append operation.

   The actual function performed by the POST method is determined by the
   server and is usually dependent on the Request-URI. The posted entity
   is subordinate to that URI in the same way that a file is subordinate
   to a directory containing it, a news article is subordinate to a
   newsgroup to which it is posted, or a record is subordinate to a
   database.

   The action performed by the POST method might not result in a
   resource that can be identified by a URI. In this case, either 200
   (OK) or 204 (No Content) is the appropriate response status,
   depending on whether or not the response includes an entity that
   describes the result.

   If a resource has been created on the origin server, the response
   SHOULD be 201 (Created) and contain an entity which describes the
   status of the request and refers to the new resource, and a Location
   header (see section 14.30).

   Responses to this method are not cachable, unless the response
   includes appropriate Cache-Control or Expires header fields. However,
   the 303 (See Other) response can be used to direct the user agent to
   retrieve a cachable resource.

   POST requests must obey the message transmission requirements set out
   in section 8.2.

 

 

 

 

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

RFC 2068                        HTTP/1.1                    January 1997


9.6 PUT

   The PUT method requests that the enclosed entity be stored under the
   supplied Request-URI. If the Request-URI refers to an already
   existing resource, the enclosed entity SHOULD be considered as a
   modified version of the one residing on the origin server. If the
   Request-URI does not point to an existing resource, and that URI is
   capable of being defined as a new resource by the requesting user
   agent, the origin server can create the resource with that URI. If a
   new resource is created, the origin server MUST inform the user agent
   via the 201 (Created) response.  If an existing resource is modified,
   either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
   to indicate successful completion of the request. If the resource
   could not be created or modified with the Request-URI, an appropriate
   error response SHOULD be given that reflects the nature of the
   problem. The recipient of the entity MUST NOT ignore any Content-*
   (e.g. Content-Range) headers that it does not understand or implement
   and MUST return a 501 (Not Implemented) response in such cases.

   If the request passes through a cache and the Request-URI identifies
   one or more currently cached entities, those entries should be
   treated as stale. Responses to this method are not cachable.

   The fundamental difference between the POST and PUT requests is
   reflected in the different meaning of the Request-URI. The URI in a
   POST request identifies the resource that will handle the enclosed
   entity.  That resource may be a data-accepting process, a gateway to
   some other protocol, or a separate entity that accepts annotations.
   In contrast, the URI in a PUT request identifies the entity enclosed
   with the request -- the user agent knows what URI is intended and the
   server MUST NOT attempt to apply the request to some other resource.
   If the server desires that the request be applied to a different URI,
   it MUST send a 301 (Moved Permanently) response; the user agent MAY
   then make its own decision regarding whether or not to redirect the
   request.

   A single resource MAY be identified by many different URIs. For
   example, an article may have a URI for identifying "the current
   version" which is separate from the URI identifying each particular
   version. In this case, a PUT request on a general URI may result in
   several other URIs being defined by the origin server.

   HTTP/1.1 does not define how a PUT method affects the state of an
   origin server.

   PUT requests must obey the message transmission requirements set out
   in section 8.2.

 


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

RFC 2068                        HTTP/1.1                    January 1997


9.7 DELETE

   The DELETE method requests that the origin server delete the resource
   identified by the Request-URI. This method MAY be overridden by human
   intervention (or other means) on the origin server. The client cannot
   be guaranteed that the operation has been carried out, even if the
   status code returned from the origin server indicates that the action
   has been completed successfully. However, the server SHOULD not
   indicate success unless, at the time the response is given, it
   intends to delete the resource or move it to an inaccessible
   location.

   A successful response SHOULD be 200 (OK) if the response includes an
   entity describing the status, 202 (Accepted) if the action has not
   yet been enacted, or 204 (No Content) if the response is OK but does
   not include an entity.

   If the request passes through a cache and the Request-URI identifies
   one or more currently cached entities, those entries should be
   treated as stale. Responses to this method are not cachable.

9.8 TRACE

   The TRACE method is used to invoke a remote, application-layer loop-
   back of the request message. The final recipient of the request
   SHOULD reflect the message received back to the client as the
   entity-body of a 200 (OK) response. The final recipient is either the
   origin server or the first proxy or gateway to receive a Max-Forwards
   value of zero (0) in the request (see section 14.31). A TRACE request
   MUST NOT include an entity.

   TRACE allows the client to see what is being received at the other
   end of the request chain and use that data for testing or diagnostic
   information. The value of the Via header field (section 14.44) is of
   particular interest, since it acts as a trace of the request chain.
   Use of the Max-Forwards header field allows the client to limit the
   length of the request chain, which is useful for testing a chain of
   proxies forwarding messages in an infinite loop.

   If successful, the response SHOULD contain the entire request message
   in the entity-body, with a Content-Type of "message/http". Responses
   to this method MUST NOT be cached.

10 Status Code Definitions

   Each Status-Code is described below, including a description of which
   method(s) it can follow and any metainformation required in the
   response.

 

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

RFC 2068                        HTTP/1.1                    January 1997


10.1 Informational 1xx

   This class of status code indicates a provisional response,
   consisting only of the Status-Line and optional headers, and is
   terminated by an empty line. Since HTTP/1.0 did not define any 1xx
   status codes, servers MUST NOT send a 1xx response to an HTTP/1.0
   client except under experimental conditions.

10.1.1 100 Continue

   The client may continue with its request. This interim response is
   used to inform the client that the initial part of the request has
   been received and has not yet been rejected by the server. The client
   SHOULD continue by sending the remainder of the request or, if the
   request has already been completed, ignore this response. The server
   MUST send a final response after the request has been completed.

10.1.2 101 Switching Protocols

   The server understands and is willing to comply with the client's
   request, via the Upgrade message header field (section 14.41), for a
   change in the application protocol being used on this connection. The
   server will switch protocols to those defined by the response's
   Upgrade header field immediately after the empty line which
   terminates the 101 response.

   The protocol should only be switched when it is advantageous to do
   so.  For example, switching to a newer version of HTTP is
   advantageous over older versions, and switching to a real-time,
   synchronous protocol may be advantageous when delivering resources
   that use such features.

10.2 Successful 2xx

   This class of status code indicates that the client's request was
   successfully received, understood, and accepted.

10.2.1 200 OK

   The request has succeeded. The information returned with the response
   is dependent on the method used in the request, for example:

   GET  an entity corresponding to the requested resource is sent in the
        response;

   HEAD the entity-header fields corresponding to the requested resource
        are sent in the response without any message-body;

 


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

RFC 2068                        HTTP/1.1                    January 1997


   POST an entity describing or containing the result of the action;

   TRACE an entity containing the request message as received by the end
        server.

10.2.2 201 Created

   The request has been fulfilled and resulted in a new resource being
   created. The newly created resource can be referenced by the URI(s)
   returned in the entity of the response, with the most specific URL
   for the resource given by a Location header field. The origin server
   MUST create the resource before returning the 201 status code. If the
   action cannot be carried out immediately, the server should respond
   with 202 (Accepted) response instead.

10.2.3 202 Accepted

   The request has been accepted for processing, but the processing has
   not been completed. The request MAY or MAY NOT eventually be acted
   upon, as it MAY be disallowed when processing actually takes place.
   There is no facility for re-sending a status code from an
   asynchronous operation such as this.

   The 202 response is intentionally non-committal. Its purpose is to
   allow a server to accept a request for some other process (perhaps a
   batch-oriented process that is only run once per day) without
   requiring that the user agent's connection to the server persist
   until the process is completed. The entity returned with this
   response SHOULD include an indication of the request's current status
   and either a pointer to a status monitor or some estimate of when the
   user can expect the request to be fulfilled.

10.2.4 203 Non-Authoritative Information

   The returned metainformation in the entity-header is not the
   definitive set as available from the origin server, but is gathered
   from a local or a third-party copy. The set presented MAY be a subset
   or superset of the original version. For example, including local
   annotation information about the resource MAY result in a superset of
   the metainformation known by the origin server. Use of this response
   code is not required and is only appropriate when the response would
   otherwise be 200 (OK).

10.2.5 204 No Content

   The server has fulfilled the request but there is no new information
   to send back. If the client is a user agent, it SHOULD NOT change its
   document view from that which caused the request to be sent. This

 

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.

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

 




相关文章

相关软件