Changeset 1174
- Timestamp:
- 13/03/11 11:39:51 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1171 r1174 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 3, 2011";361 content: "Expires September 14, 2011"; 362 362 } 363 363 @bottom-right { … … 410 410 <meta name="dct.creator" content="Reschke, J. F."> 411 411 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 412 <meta name="dct.issued" scheme="ISO8601" content="2011-03-1 2">412 <meta name="dct.issued" scheme="ISO8601" content="2011-03-13"> 413 413 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 414 414 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 442 442 </tr> 443 443 <tr> 444 <td class="left">Expires: September 1 3, 2011</td>444 <td class="left">Expires: September 14, 2011</td> 445 445 <td class="right">HP</td> 446 446 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">March 1 2, 2011</td>497 <td class="right">March 13, 2011</td> 498 498 </tr> 499 499 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on September 1 3, 2011.</p>525 <p>This Internet-Draft will expire on September 14, 2011.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 970 970 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> <span id="rfc.iref.a.1"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates 971 971 the received requests to the underlying server's protocol. Gateways are often used for load balancing, "accelerator" caching, 972 or partitioning HTTP services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin973 server for the target resource; the requesting client will not be aware that it is communicating with a gateway. A gateway974 communicates with the client as if the gateway is the origin server and thus is subject to all of the requirements on origin975 servers for that connection. A gateway communicates with inbound servers using any protocol it desires, including private976 extensions to HTTP that are outside the scope of this specification.972 or partitioning HTTP services across multiple machines. Gateways behave as an origin server on the outbound connection and 973 as a proxy on the inbound connection. All HTTP requirements applicable to an origin server also apply to the outbound communication 974 of a gateway. A gateway communicates with inbound servers using any protocol it desires, including private extensions to HTTP 975 that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party 976 HTTP servers <em class="bcp14">SHOULD</em> comply with HTTP proxy requirements on the gateway's inbound connection. 977 977 </p> 978 978 <p id="rfc.section.2.3.p.8"><span id="rfc.iref.t.2"></span> A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered … … 1308 1308 <li> 1309 1309 <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing 1310 field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy 1311 or gateway, the proxy or gateway <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection.1310 field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy, 1311 the proxy <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection. 1312 1312 If this is a response message received by a user-agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection. 1313 1313 </p> … … 1433 1433 <p id="rfc.section.4.1.2.p.10"><span id="rfc.iref.a.4"></span> The "authority form" is only used by the CONNECT request method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1434 1434 </p> 1435 <p id="rfc.section.4.1.2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server or gateway ("origin form").1436 In this case,the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified1435 <p id="rfc.section.4.1.2.p.11"><span id="rfc.iref.o.3"></span> The most common form of request-target is that used when making a request to an origin server ("origin form"). In this case, 1436 the absolute path and query components of the URI <em class="bcp14">MUST</em> be transmitted as the request-target, and the authority component <em class="bcp14">MUST</em> be transmitted in a Host header field. For example, a client wishing to retrieve a representation of the resource, as identified 1437 1437 above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and 1438 1438 send the lines: … … 1818 1818 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2> 1819 1819 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> 1820 <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP1821 servers and causing congestion on the Internet. The use of inline images and other associated data often requires a client1822 to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results1823 from aprototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.1820 <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established for each request, increasing the load on HTTP servers 1821 and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make 1822 multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a 1823 prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. 1824 1824 </p> 1825 1825 <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p> … … 2149 2149 </li> 2150 2150 </ol> 2151 <p id="rfc.section.9.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires 2152 a Date. 2151 <p id="rfc.section.9.3.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient. 2153 2152 </p> 2154 2153 <p id="rfc.section.9.3.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it … … 2168 2167 <div id="rfc.iref.h.10"></div> 2169 2168 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.host" href="#header.host">Host</a></h2> 2170 <p id="rfc.section.9.4.p.1">The "Host" header field specifies the Internet host and port number of the resource being requested, allowing the origin server 2171 or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names 2172 on a single IP address. 2173 </p> 2174 <p id="rfc.section.9.4.p.2">The Host field value <em class="bcp14">MUST</em> represent the naming authority of the origin server or gateway given by the original URL obtained from the user or referring 2175 resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section 2.6.1</a>). 2169 <p id="rfc.section.9.4.p.1">The "Host" header field in a request provides the host and port information from the target resource's URI, enabling the origin 2170 server to distinguish between resources while servicing requests for multiple host names on a single IP address. Since the 2171 Host field-value is critical information for handling a request, it <em class="bcp14">SHOULD</em> be sent as the first header field following the Request-Line. 2176 2172 </p> 2177 2173 <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 2178 2174 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.6.1</a> 2179 </pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 2180 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 2181 </p> 2175 </pre><p id="rfc.section.9.4.p.3">A client <em class="bcp14">MUST</em> send a Host header field in all HTTP/1.1 request messages. If the target resource's URI includes an authority component, then 2176 the Host field-value <em class="bcp14">MUST</em> be identical to that authority component after excluding any userinfo (<a href="#http.uri" title="http URI scheme">Section 2.6.1</a>). If the authority component is missing or undefined for the target resource's URI, then the Host header field <em class="bcp14">MUST</em> be sent with an empty field-value. 2177 </p> 2178 <p id="rfc.section.9.4.p.4">For example, a GET request to the origin server for <http://www.example.org/pub/WWW/> would begin with:</p> 2182 2179 <div id="rfc.figure.u.62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 2183 2180 Host: www.example.org 2184 </pre><p id="rfc.section.9.4.p.6">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name 2185 for the service being requested, then the Host header field <em class="bcp14">MUST</em> be given with an empty value. An HTTP/1.1 proxy <em class="bcp14">MUST</em> ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being 2186 requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field. 2187 </p> 2188 <p id="rfc.section.9.4.p.7">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host. 2181 </pre><p id="rfc.section.9.4.p.6">The Host header field <em class="bcp14">MUST</em> be sent in an HTTP/1.1 request even if the request-target is in the form of an absolute-URI, since this allows the Host information 2182 to be forwarded through ancient HTTP/1.0 proxies that might not have implemented Host. 2183 </p> 2184 <p id="rfc.section.9.4.p.7">When an HTTP/1.1 proxy receives a request with a request-target in the form of an absolute-URI, the proxy <em class="bcp14">MUST</em> ignore the received Host header field (if any) and instead replace it with the host information of the request-target. When 2185 a proxy forwards a request, it <em class="bcp14">MUST</em> generate the Host header field based on the received absolute-URI rather than the received Host. 2186 </p> 2187 <p id="rfc.section.9.4.p.8">Since the Host header field acts as an application-level routing mechanism, it is a frequent target for malware seeking to 2188 poison a shared cache or redirect a request to an unintended server. An interception proxy is particularly vulnerable if it 2189 relies on the Host header field value for redirecting requests to internal servers, or for use as a cache key in a shared 2190 cache, without first verifying that the intercepted connection is targeting a valid IP address for that host. 2191 </p> 2192 <p id="rfc.section.9.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request 2193 message that contains more than one Host header field or a Host header field with an invalid field-value. 2194 </p> 2195 <p id="rfc.section.9.4.p.10">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host. 2189 2196 </p> 2190 2197 <div id="rfc.iref.t.5"></div> … … 2332 2339 <div id="rfc.iref.h.15"></div> 2333 2340 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.via" href="#header.via">Via</a></h2> 2334 <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server2335 on requests,and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities2341 <p id="rfc.section.9.9.p.1">The "Via" header field <em class="bcp14">MUST</em> be sent by proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, 2342 and between the origin server and the client on responses. It is analogous to the "Received" field defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.7">Section 3.6.7</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities 2336 2343 of all senders along the request/response chain. 2337 2344 </p> … … 2352 2359 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 2353 2360 </p> 2354 <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy or gatewaythat has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.2355 </p> 2356 <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and2357 Server headerfields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message.2361 <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 2362 </p> 2363 <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy, analogous to the User-Agent and Server header 2364 fields. However, all comments in the Via field are optional and <em class="bcp14">MAY</em> be removed by any recipient prior to forwarding the message. 2358 2365 </p> 2359 2366 <p id="rfc.section.9.9.p.7">For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses … … 2362 2369 </p> 2363 2370 <div id="rfc.figure.u.71"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 2364 </pre><p id="rfc.section.9.9.p.9">Proxies and gatewaysused as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host.2371 </pre><p id="rfc.section.9.9.p.9">Proxies used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 2365 2372 </p> 2366 2373 <p id="rfc.section.9.9.p.10">For organizations that have strong privacy requirements for hiding internal structures, a proxy <em class="bcp14">MAY</em> combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. … … 3014 3021 address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created 3015 3022 serious problems. The Internet will also be able to recover the IP addresses that have been allocated for the sole purpose 3016 of allowing special-purpose domain names to be used in root-level HTTP URLs. Given the rate of growth of the Web, and the3017 number of servers already deployed, it is extremely important that all implementations of HTTP (including updates to existing3018 HTTP/1.0 applications)correctly implement these requirements:3023 of allowing special-purpose domain names to be used. Given the rate of growth of the Web, and the number of servers already 3024 deployed, it is extremely important that all implementations of HTTP (including updates to existing HTTP/1.0 applications) 3025 correctly implement these requirements: 3019 3026 </p> 3020 3027 <ul> -
draft-ietf-httpbis/latest/p2-semantics.html
r1168 r1174 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 2, 2011";361 content: "Expires September 14, 2011"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-03-1 1">411 <meta name="dct.issued" scheme="ISO8601" content="2011-03-13"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: September 1 2, 2011</td>442 <td class="left">Expires: September 14, 2011</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">March 1 1, 2011</td>495 <td class="right">March 13, 2011</td> 496 496 </tr> 497 497 </tbody> … … 520 520 in progress”. 521 521 </p> 522 <p>This Internet-Draft will expire on September 1 2, 2011.</p>522 <p>This Internet-Draft will expire on September 14, 2011.</p> 523 523 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 524 524 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1462 1462 <div id="rfc.iref.m.7"></div> 1463 1463 <p id="rfc.section.7.8.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message-body of a 200 (OK) response. The final recipient is either 1464 the origin server or the first proxy or gatewayto receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.1464 the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body. 1465 1465 </p> 1466 1466 <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing … … 2034 2034 <div id="rfc.iref.h.6"></div> 2035 2035 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 2036 <p id="rfc.section.9.5.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of times that the request is forwarded by proxies or gateways. This can be useful when the client2037 is attemptingto trace a request which appears to be failing or looping in mid-chain.2036 <p id="rfc.section.9.5.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 2037 to trace a request which appears to be failing or looping in mid-chain. 2038 2038 </p> 2039 2039 <div id="rfc.figure.u.16"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = "Max-Forwards" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> 2040 2040 <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> 2041 2041 </pre><p id="rfc.section.9.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 2042 <p id="rfc.section.9.5.p.4">Each proxy or gatewayrecipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1).2042 <p id="rfc.section.9.5.p.4">Each recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). 2043 2043 </p> 2044 2044 <p id="rfc.section.9.5.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. -
draft-ietf-httpbis/latest/p3-payload.html
r1167 r1174 359 359 } 360 360 @bottom-center { 361 content: "Expires September 1 2, 2011";361 content: "Expires September 14, 2011"; 362 362 } 363 363 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-03-1 1">410 <meta name="dct.issued" scheme="ISO8601" content="2011-03-13"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: September 1 2, 2011</td>436 <td class="left">Expires: September 14, 2011</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 491 491 <tr> 492 492 <td class="left"></td> 493 <td class="right">March 1 1, 2011</td>493 <td class="right">March 13, 2011</td> 494 494 </tr> 495 495 </tbody> … … 517 517 in progress”. 518 518 </p> 519 <p>This Internet-Draft will expire on September 1 2, 2011.</p>519 <p>This Internet-Draft will expire on September 14, 2011.</p> 520 520 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 521 521 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1364 1364 <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = <base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>> 1365 1365 </pre><p id="rfc.section.6.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user 1366 agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways<em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received.1366 agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received. 1367 1367 </p> 1368 1368 <p id="rfc.section.6.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding -
draft-ietf-httpbis/latest/p6-cache.html
r1166 r1174 362 362 } 363 363 @bottom-center { 364 content: "Expires September 1 2, 2011";364 content: "Expires September 14, 2011"; 365 365 } 366 366 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2011-03-1 1">410 <meta name="dct.issued" scheme="ISO8601" content="2011-03-13"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 412 412 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: September 1 2, 2011</td>436 <td class="left">Expires: September 14, 2011</td> 437 437 <td class="right">J. Mogul</td> 438 438 </tr> … … 495 495 <tr> 496 496 <td class="left"></td> 497 <td class="right">March 1 1, 2011</td>497 <td class="right">March 13, 2011</td> 498 498 </tr> 499 499 </tbody> … … 521 521 in progress”. 522 522 </p> 523 <p>This Internet-Draft will expire on September 1 2, 2011.</p>523 <p>This Internet-Draft will expire on September 14, 2011.</p> 524 524 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 525 525 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 862 862 </p> 863 863 <div class="note" id="rfc.section.2.3.1.1.p.4"> 864 <p> <b>Note:</b> RFC 2616 (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-13.9">Section 13.9</a>) required that caches do not calculate heuristic freshness for UR Ls with query components (i.e., those containing '?'). In864 <p> <b>Note:</b> RFC 2616 (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-13.9">Section 13.9</a>) required that caches do not calculate heuristic freshness for URIs with query components (i.e., those containing '?'). In 865 865 practice, this has not been widely implemented. Therefore, servers are encouraged to send explicit directives (e.g., Cache-Control: 866 866 no-cache) if they wish to preclude caching. … … 1068 1068 </p> 1069 1069 </div> 1070 <p id="rfc.section.3.2.p.4">An intermediary (i.e., a proxy or gateway, whether or not it implements a cache) <em class="bcp14">MUST</em> pass cache directives through, regardless of their significance to that application, since the directives might be applicable 1071 to all recipients along the request/response chain. It is not possible to target a directive to a specific cache. 1070 <p id="rfc.section.3.2.p.4">A proxy, whether or not it implements a cache, <em class="bcp14">MUST</em> pass cache directives through in forwarded messages, regardless of their significance to that application, since the directives 1071 might be applicable to all recipients along the request/response chain. It is not possible to target a directive to a specific 1072 cache. 1072 1073 </p> 1073 1074 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#header.cache-control" class="smpl">Cache-Control</a> = "Cache-Control" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.cache-control" class="smpl">Cache-Control-v</a>
Note: See TracChangeset
for help on using the changeset viewer.