Changeset 1174


Ignore:
Timestamp:
Mar 13, 2011, 4:39:51 AM (9 years ago)
Author:
fielding@…
Message:

generate HTML

Location:
draft-ietf-httpbis/latest
Files:
4 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r1171 r1174  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 13, 2011";
     361       content: "Expires September 14, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    412       <meta name="dct.issued" scheme="ISO8601" content="2011-03-12">
     412      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    414414      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    442442            </tr>
    443443            <tr>
    444                <td class="left">Expires: September 13, 2011</td>
     444               <td class="left">Expires: September 14, 2011</td>
    445445               <td class="right">HP</td>
    446446            </tr>
    … …  
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">March 12, 2011</td>
     497               <td class="right">March 13, 2011</td>
    498498            </tr>
    499499         </tbody>
    … …  
    523523         in progress”.
    524524      </p>
    525       <p>This Internet-Draft will expire on September 13, 2011.</p>
     525      <p>This Internet-Draft will expire on September 14, 2011.</p>
    526526      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    527527      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    970970      <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
    971971         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 origin
    973          server for the target resource; the requesting client will not be aware that it is communicating with a gateway. A gateway
    974          communicates with the client as if the gateway is the origin server and thus is subject to all of the requirements on origin
    975          servers for that connection. A gateway communicates with inbound servers using any protocol it desires, including private
    976          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.
    977977      </p>
    978978      <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
    … …  
    13081308         <li>
    13091309            <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.
    13121312               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.
    13131313            </p>
    … …  
    14331433      <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>).
    14341434      </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 identified
     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 ("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
    14371437         above, directly from the origin server would open (or reuse) a TCP connection to port 80 of the host "www.example.org" and
    14381438         send the lines:
    … …  
    18181818      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
    18191819      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<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 HTTP
    1821          servers and causing congestion on the Internet. The use of inline images and other associated data often requires a client
    1822          to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results
    1823          from a 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>.
     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>.
    18241824      </p>
    18251825      <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
    … …  
    21492149         </li>
    21502150      </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.
    21532152      </p>
    21542153      <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
    … …  
    21682167      <div id="rfc.iref.h.10"></div>
    21692168      <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a>&nbsp;<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&nbsp;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.
    21762172      </p>
    21772173      <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>
    21782174  <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&nbsp;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 &lt;http://www.example.org/pub/WWW/&gt; 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&nbsp;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 &lt;http://www.example.org/pub/WWW/&gt; would begin with:</p>
    21822179      <div id="rfc.figure.u.62"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
    21832180Host: 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.
    21892196      </p>
    21902197      <div id="rfc.iref.t.5"></div>
    … …  
    23322339      <div id="rfc.iref.h.15"></div>
    23332340      <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a>&nbsp;<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 server
    2335          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 capabilities
     2341      <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
    23362343         of all senders along the request/response chain.
    23372344      </p>
    … …  
    23522359         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.
    23532360      </p>
    2354       <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy or gateway 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.
    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 and
    2357          Server header 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.
     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.
    23582365      </p>
    23592366      <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
    … …  
    23622369      </p>
    23632370      <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 gateways 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.
     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.
    23652372      </p>
    23662373      <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.
    … …  
    30143021         address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created
    30153022         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 the
    3017          number of servers already deployed, it is extremely important that all implementations of HTTP (including updates to existing
    3018          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:
    30193026      </p>
    30203027      <ul>

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1168 r1174  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 12, 2011";
     361       content: "Expires September 14, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    409409      <meta name="dct.creator" content="Reschke, J. F.">
    410410      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    411       <meta name="dct.issued" scheme="ISO8601" content="2011-03-11">
     411      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
    412412      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    413413      <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 &#34;HTTP/1.1&#34; 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.">
    … …  
    440440            </tr>
    441441            <tr>
    442                <td class="left">Expires: September 12, 2011</td>
     442               <td class="left">Expires: September 14, 2011</td>
    443443               <td class="right">HP</td>
    444444            </tr>
    … …  
    493493            <tr>
    494494               <td class="left"></td>
    495                <td class="right">March 11, 2011</td>
     495               <td class="right">March 13, 2011</td>
    496496            </tr>
    497497         </tbody>
    … …  
    520520         in progress”.
    521521      </p>
    522       <p>This Internet-Draft will expire on September 12, 2011.</p>
     522      <p>This Internet-Draft will expire on September 14, 2011.</p>
    523523      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    524524      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    14621462      <div id="rfc.iref.m.7"></div>
    14631463      <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 gateway 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&nbsp;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&nbsp;9.5</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message-body.
    14651465      </p>
    14661466      <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
    … …  
    20342034      <div id="rfc.iref.h.6"></div>
    20352035      <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<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&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;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 client
    2037          is attempting to 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&nbsp;7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;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.
    20382038      </p>
    20392039      <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>
    20402040  <a href="#header.max-forwards" class="smpl">Max-Forwards-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a>
    20412041</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 gateway 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).
     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).
    20432043      </p>
    20442044      <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  
    359359  }
    360360  @bottom-center {
    361        content: "Expires September 12, 2011";
     361       content: "Expires September 14, 2011";
    362362  }
    363363  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-03-11">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: September 12, 2011</td>
     436               <td class="left">Expires: September 14, 2011</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    491491            <tr>
    492492               <td class="left"></td>
    493                <td class="right">March 11, 2011</td>
     493               <td class="right">March 13, 2011</td>
    494494            </tr>
    495495         </tbody>
    … …  
    517517         in progress”.
    518518      </p>
    519       <p>This Internet-Draft will expire on September 12, 2011.</p>
     519      <p>This Internet-Draft will expire on September 14, 2011.</p>
    520520      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    521521      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    13641364  <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = &lt;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>&gt;
    13651365</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.
    13671367      </p>
    13681368      <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  
    362362  }
    363363  @bottom-center {
    364        content: "Expires September 12, 2011";
     364       content: "Expires September 14, 2011";
    365365  }
    366366  @bottom-right {
    … …  
    408408      <meta name="dct.creator" content="Reschke, J. F.">
    409409      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    410       <meta name="dct.issued" scheme="ISO8601" content="2011-03-11">
     410      <meta name="dct.issued" scheme="ISO8601" content="2011-03-13">
    411411      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    412412      <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 &#34;HTTP/1.1&#34; 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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: September 12, 2011</td>
     436               <td class="left">Expires: September 14, 2011</td>
    437437               <td class="right">J. Mogul</td>
    438438            </tr>
    … …  
    495495            <tr>
    496496               <td class="left"></td>
    497                <td class="right">March 11, 2011</td>
     497               <td class="right">March 13, 2011</td>
    498498            </tr>
    499499         </tbody>
    … …  
    521521         in progress”.
    522522      </p>
    523       <p>This Internet-Draft will expire on September 12, 2011.</p>
     523      <p>This Internet-Draft will expire on September 14, 2011.</p>
    524524      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    525525      <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    862862      </p>
    863863      <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 URLs with query components (i.e., those containing '?'). In
     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 URIs with query components (i.e., those containing '?'). In
    865865            practice, this has not been widely implemented. Therefore, servers are encouraged to send explicit directives (e.g., Cache-Control:
    866866            no-cache) if they wish to preclude caching.
    … …  
    10681068         </p>
    10691069      </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.
    10721073      </p>
    10731074      <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.