http1.1---4 (轉)

worldblog發表於2007-12-04
http1.1---4 (轉)[@more@]

 


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 ntify the
  re. 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 traner codings have been removed. Section 4.4 defines how the
  length of a message-body is detened.

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 Inte. 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 implementation are in [26].

  Persistent HTTP connections have a number of advantages:

  o  By opening and closing fewer TCP connections, 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 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
  perfothe 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-trtime 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, ing 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 l-
  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.

誰翻譯了別忘了給我發一份

 


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-988364/,如需轉載,請註明出處,否則將追究法律責任。

相關文章