14.30 Location
The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the
request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URL for automatic redirection to the resource. The
field value consists of a single absolute URL.
Location = "Location" ":" absoluteURI
An example is
Location: http://www.w3.org/pub/WWW/People.html
Note: The Content-Location header field (section 14.15) differs
from Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location
and Content-Location. Also see section 13.10 for cache requirements
of some methods.
14.31 Max-Forwards
The Max-Forwards request-header field may be used with the TRACE
method (section 14.31) to limit the number of proxies or gateways
that can forward the request to the next inbound server. This can be
useful when the client is attempting to trace a request chain which
appears to be failing or looping in mid-chain.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
Fielding, et. al. Standards Track [Page 125]
RFC 2068 HTTP/1.1 January 1997
The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message may be forwarded.
Each proxy or gateway recipient of a TRACE request containing a Max-
Forwards header field SHOULD check and update its value prior to
forwarding the request. If the received value is zero (0), the
recipient SHOULD NOT forward the request; instead, it SHOULD respond
as the final recipient with a 200 (OK) response containing the
received request message as the response entity-body (as described in
section 9.8). If the received Max-Forwards value is greater than
zero, then the forwarded message SHOULD contain an updated Max-
Forwards field with a value decremented by one (1).
The Max-Forwards header field SHOULD be ignored for all other methods
defined by this specification and for any extension methods for which
it is not explicitly referred to as part of that method definition.
14.32 Pragma
The Pragma general-header field is used to include implementation-
specific directives that may apply to any recipient along the
request/response chain. All pragma directives specify optional
behavior from the viewpoint of the protocol; however, some systems
MAY require that behavior be consistent with the directives.
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
When the no-cache directive is present in a request message, an
application SHOULD forward the request toward the origin server even
if it has a cached copy of what is being requested. This pragma
directive has the same semantics as the no-cache cache-directive (see
section 14.9) and is defined here for backwards compatibility with
HTTP/1.0. Clients SHOULD include both header fields when a no-cache
request is sent to a server not known to be HTTP/1.1 compliant.
Pragma directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives may be applicable to all recipients along the
request/response chain. It is not possible to specify a pragma for a
specific recipient; however, any pragma directive not relevant to a
recipient SHOULD be ignored by that recipient.
Fielding, et. al. Standards Track [Page 126]
RFC 2068 HTTP/1.1 January 1997
HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
caches SHOULD treat "Pragma: no-cache" as if the client had sent
"Cache-Control: no-cache". No new Pragma directives will be defined
in HTTP.