Changeset 2092 for draft-ietf-httpbis/latest
- Timestamp:
- 06/01/13 09:44:29 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2091 r2092 449 449 } 450 450 @bottom-center { 451 content: "Expires July 9, 2013";451 content: "Expires July 10, 2013"; 452 452 } 453 453 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2013-01-0 5">496 <meta name="dct.issued" scheme="ISO8601" content="2013-01-06"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 522 522 <tr> 523 523 <td class="left">Intended status: Standards Track</td> 524 <td class="right">January 5, 2013</td>524 <td class="right">January 6, 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: July 9, 2013</td>527 <td class="left">Expires: July 10, 2013</td> 528 528 <td class="right"></td> 529 529 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on July 9, 2013.</p>555 <p>This Internet-Draft will expire on July 10, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 636 636 <li><a href="#rfc.section.5">5.</a> <a href="#request.header.fields">Request Header Fields</a><ul> 637 637 <li><a href="#rfc.section.5.1">5.1</a> <a href="#request.controls">Controls</a><ul> 638 <li><a href="#rfc.section.5.1.1">5.1.1</a> <a href="#header.max-forwards">Max-Forwards</a></li> 639 <li><a href="#rfc.section.5.1.2">5.1.2</a> <a href="#header.expect">Expect</a><ul> 640 <li><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li> 638 <li><a href="#rfc.section.5.1.1">5.1.1</a> <a href="#header.expect">Expect</a><ul> 639 <li><a href="#rfc.section.5.1.1.1">5.1.1.1</a> <a href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></li> 641 640 </ul> 642 641 </li> 642 <li><a href="#rfc.section.5.1.2">5.1.2</a> <a href="#header.max-forwards">Max-Forwards</a></li> 643 643 </ul> 644 644 </li> … … 880 880 <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section 3.1.4.2</a></td> 881 881 </tr> 882 <tr>883 <td class="left">Expires</td>884 <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>885 </tr>886 882 </tbody> 887 883 </table> … … 1381 1377 are defined to be cacheable. In general, safe methods that do not depend on a current or authoritative response are cacheable, 1382 1378 though the overwhelming majority of caches only support GET and HEAD. HTTP requirements for cache behavior and cacheable responses 1383 are defined in <a href="#Part6" id="rfc.xref.Part6. 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.1379 are defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. 1384 1380 </p> 1385 1381 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h2> … … 1399 1395 to be completed without transferring data already held by the client. 1400 1396 </p> 1401 <p id="rfc.section.4.3.1.p.5">A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some 1397 <p id="rfc.section.4.3.1.p.5">The response to a GET request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 1398 </p> 1399 <p id="rfc.section.4.3.1.p.6">A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some 1402 1400 existing implementations to reject the request. 1403 </p>1404 <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).1405 1401 </p> 1406 1402 <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a> <a id="HEAD" href="#HEAD">HEAD</a></h3> 1407 1403 <div id="rfc.iref.h.1"></div> 1408 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response (i.e., the response terminates at the end of the header block). The metadata contained1409 in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the1410 selected representation without transferring the representation data. This method is often used for testing hypertext links1411 for validity, accessibility, and recent modification.1412 </p> 1413 <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.1404 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response (i.e., the response terminates at the end of the header block). Aside from the payload 1405 header fields (<a href="#payload" title="Payload Semantics">Section 3.3</a>), the server <em class="bcp14">SHOULD</em> send the same header fields in response to a HEAD request as it would have sent if the request had been a GET. This method 1406 can be used for obtaining metadata about the selected representation without transferring the representation data. This method 1407 is often used for testing hypertext links for validity, accessibility, and recent modification. 1408 </p> 1409 <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A HEAD response might also have an effect on previously cached responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. 1414 1410 </p> 1415 1411 <p id="rfc.section.4.3.2.p.3">A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some … … 1586 1582 this specification, but might be defined by future extensions to HTTP. A server <em class="bcp14">MUST</em> generate a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a value of "0" if no payload body is to be sent in the response. 1587 1583 </p> 1588 <p id="rfc.section.4.3.7.p.7">A client <em class="bcp14">MAY</em> send a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field in an OPTIONS request to target a specific recipient in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 5.1. 1</a>). A proxy <em class="bcp14">MUST NOT</em> generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.1584 <p id="rfc.section.4.3.7.p.7">A client <em class="bcp14">MAY</em> send a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field in an OPTIONS request to target a specific recipient in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 5.1.2</a>). A proxy <em class="bcp14">MUST NOT</em> generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field. 1589 1585 </p> 1590 1586 <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a> <a id="TRACE" href="#TRACE">TRACE</a></h3> 1591 1587 <div id="rfc.iref.t.1"></div> 1592 <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 5.1. 1</a>).1588 <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section 5.1.2</a>). 1593 1589 </p> 1594 1590 <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> send a message body in a TRACE request. … … 1620 1616 <tbody> 1621 1617 <tr> 1618 <td class="left">Cache-Control</td> 1619 <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 1620 </tr> 1621 <tr> 1622 <td class="left">Expect</td> 1623 <td class="left"><a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 5.1.1</a></td> 1624 </tr> 1625 <tr> 1622 1626 <td class="left">Host</td> 1623 1627 <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> … … 1625 1629 <tr> 1626 1630 <td class="left">Max-Forwards</td> 1627 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 5.1. 1</a></td>1628 </tr> 1629 <tr> 1630 <td class="left"> Expect</td>1631 <td class="left"><a href=" #header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 5.1.2</a></td>1631 <td class="left"><a href="#header.max-forwards" id="rfc.xref.header.max-forwards.3" title="Max-Forwards">Section 5.1.2</a></td> 1632 </tr> 1633 <tr> 1634 <td class="left">Pragma</td> 1635 <td class="left"><a href="p6-cache.html#header.pragma" title="Pragma">Section 7.4</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 1632 1636 </tr> 1633 1637 <tr> 1634 1638 <td class="left">Range</td> 1635 1639 <td class="left"><a href="p5-range.html#header.range" title="Range">Section 5.4</a> of <a href="#Part5" id="rfc.xref.Part5.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a></td> 1640 </tr> 1641 <tr> 1642 <td class="left">TE</td> 1643 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td> 1636 1644 </tr> 1637 1645 </tbody> 1638 1646 </table> 1639 1647 </div> 1640 <div id="rfc.iref.m.1"></div>1641 <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3>1642 <p id="rfc.section.5.1.1.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting1643 to trace a request that appears to be failing or looping mid-chain.1644 </p>1645 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.17"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>1646 </pre><p id="rfc.section.5.1.1.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>1647 <p id="rfc.section.5.1.1.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).1648 </p>1649 <p id="rfc.section.5.1.1.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods.1650 </p>1651 1648 <div id="rfc.iref.e.1"></div> 1652 <h3 id="rfc.section.5.1. 2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="header.expect" href="#header.expect">Expect</a></h3>1653 <p id="rfc.section.5.1. 2.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p>1654 <div id="rfc.figure.u.2 1"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a>1649 <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="header.expect" href="#header.expect">Expect</a></h3> 1650 <p id="rfc.section.5.1.1.p.1">The "Expect" header field is used to indicate that particular server behaviors are required by the client.</p> 1651 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span> <a href="#header.expect" class="smpl">Expect</a> = 1#<a href="#header.expect" class="smpl">expectation</a> 1655 1652 1656 1653 <a href="#header.expect" class="smpl">expectation</a> = <a href="#header.expect" class="smpl">expect-name</a> [ <a href="#imported.abnf" class="smpl">BWS</a> "=" <a href="#imported.abnf" class="smpl">BWS</a> <a href="#header.expect" class="smpl">expect-value</a> ] … … 1660 1657 <a href="#header.expect" class="smpl">expect-name</a> = <a href="#imported.abnf" class="smpl">token</a> 1661 1658 <a href="#header.expect" class="smpl">expect-value</a> = <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> 1662 </pre><p id="rfc.section.5.1. 2.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand1659 </pre><p id="rfc.section.5.1.1.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand 1663 1660 or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a <a href="#status.4xx" class="smpl">4xx</a> status code other than 417. 1664 1661 </p> 1665 <p id="rfc.section.5.1. 2.p.4">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p>1666 <p id="rfc.section.5.1. 2.p.5">The Expect header field <em class="bcp14">MUST</em> be forwarded if the request is forwarded.1667 </p> 1668 <p id="rfc.section.5.1. 2.p.6">Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect header field.</p>1669 <div id="rfc.iref.4 6"></div>1662 <p id="rfc.section.5.1.1.p.4">Comparison is case-insensitive for names (expect-name), and case-sensitive for values (expect-value).</p> 1663 <p id="rfc.section.5.1.1.p.5">The Expect header field <em class="bcp14">MUST</em> be forwarded if the request is forwarded. 1664 </p> 1665 <p id="rfc.section.5.1.1.p.6">Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect header field.</p> 1666 <div id="rfc.iref.44"></div> 1670 1667 <div id="rfc.iref.e.2"></div> 1671 <h4 id="rfc.section.5.1. 2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4>1672 <p id="rfc.section.5.1. 2.1.p.1">The only expectation defined by this specification is:</p>1673 <p id="rfc.section.5.1. 2.1.p.2"> <dfn>100-continue</dfn>1668 <h4 id="rfc.section.5.1.1.1"><a href="#rfc.section.5.1.1.1">5.1.1.1</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4> 1669 <p id="rfc.section.5.1.1.1.p.1">The only expectation defined by this specification is:</p> 1670 <p id="rfc.section.5.1.1.1.p.2"> <dfn>100-continue</dfn> 1674 1671 </p> 1675 1672 <ul class="empty"> … … 1678 1675 </li> 1679 1676 </ul> 1680 <p id="rfc.section.5.1. 2.1.p.3">The primary purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 6.2.1</a>) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept1677 <p id="rfc.section.5.1.1.1.p.3">The primary purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 6.2.1</a>) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept 1681 1678 the request (based on the request header fields) before the client sends the payload body. In some cases, it might either 1682 1679 be inappropriate or highly inefficient for the client to send the payload body if the server will reject the message without 1683 1680 looking at the body. 1684 1681 </p> 1685 <p id="rfc.section.5.1. 2.1.p.4">Requirements for HTTP/1.1 clients: </p>1682 <p id="rfc.section.5.1.1.1.p.4">Requirements for HTTP/1.1 clients: </p> 1686 1683 <ul> 1687 1684 <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the payload body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation. … … 1690 1687 </li> 1691 1688 </ul> 1692 <p id="rfc.section.5.1. 2.1.p.5">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:1689 <p id="rfc.section.5.1.1.1.p.5">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect: 1693 1690 100-continue" without receiving either a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has 1694 1691 never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the payload body. 1695 1692 </p> 1696 <p id="rfc.section.5.1. 2.1.p.6">Requirements for HTTP/1.1 origin servers: </p>1693 <p id="rfc.section.5.1.1.1.p.6">Requirements for HTTP/1.1 origin servers: </p> 1697 1694 <ul> 1698 1695 <li>Upon receiving a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request. … … 1714 1711 </li> 1715 1712 </ul> 1716 <p id="rfc.section.5.1. 2.1.p.7">Requirements for HTTP/1.1 proxies: </p>1713 <p id="rfc.section.5.1.1.1.p.7">Requirements for HTTP/1.1 proxies: </p> 1717 1714 <ul> 1718 1715 <li>If a proxy receives a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 … … 1726 1723 </li> 1727 1724 </ul> 1725 <div id="rfc.iref.m.1"></div> 1726 <h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3> 1727 <p id="rfc.section.5.1.2.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting 1728 to trace a request that appears to be failing or looping mid-chain. 1729 </p> 1730 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span> <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a> 1731 </pre><p id="rfc.section.5.1.2.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p> 1732 <p id="rfc.section.5.1.2.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). 1733 </p> 1734 <p id="rfc.section.5.1.2.p.5">The Max-Forwards header field <em class="bcp14">MAY</em> be ignored for all other request methods. 1735 </p> 1728 1736 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="request.conditionals" href="#request.conditionals">Conditionals</a></h2> 1729 1737 <p id="rfc.section.5.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the <a href="#resources" class="smpl">target resource</a>. Each precondition is based on metadata that is expected to change if the selected representation of the target resource … … 2038 2046 </tr> 2039 2047 <tr> 2040 <td class="left">TE</td>2041 <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a></td>2042 </tr>2043 <tr>2044 2048 <td class="left">User-Agent</td> 2045 2049 <td class="left"><a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 5.5.3</a></td> … … 2386 2390 server intends to send a final response after the request has been fully received and acted upon. 2387 2391 </p> 2388 <p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#use.of.the.100.status" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 5.1. 2.1</a>. The client ought to continue sending the request and discard the 100 response.2392 <p id="rfc.section.6.2.1.p.2">When the request contains an <a href="#header.expect" class="smpl">Expect</a> header field that includes a <a href="#use.of.the.100.status" class="smpl">100-continue</a> expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in <a href="#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 5.1.1.1</a>. The client ought to continue sending the request and discard the 100 response. 2389 2393 </p> 2390 2394 <p id="rfc.section.6.2.1.p.3">If the request did not contain an <a href="#header.expect" class="smpl">Expect</a> header field containing the <a href="#use.of.the.100.status" class="smpl">100-continue</a> expectation, the client can simply discard this interim response. … … 2419 2423 <dd>a representation containing the request message as received by the end server.</dd> 2420 2424 </dl> 2421 <p id="rfc.section.6.3.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6. 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses.2425 <p id="rfc.section.6.3.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses. 2422 2426 </p> 2423 2427 <div id="rfc.iref.72"></div> … … 2448 2452 applicable along the same request path (through the same proxies). 2449 2453 </p> 2450 <p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6. 9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), which has the advantage of being applicable to responses with any status code.2454 <p id="rfc.section.6.3.4.p.2">The 203 response is similar to the Warning code of 214 Transformation Applied (<a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), which has the advantage of being applicable to responses with any status code. 2451 2455 </p> 2452 2456 <div id="rfc.iref.72"></div> … … 2531 2535 <p id="rfc.section.6.4.1.p.3">If the server has a preferred choice, the server <em class="bcp14">SHOULD</em> generate a <a href="#header.location" class="smpl">Location</a> header field containing a preferred choice's URI reference. The user agent <em class="bcp14">MAY</em> use the Location field value for automatic redirection. 2532 2536 </p> 2533 <p id="rfc.section.6.4.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1 0"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 300 responses.2537 <p id="rfc.section.6.4.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 300 responses. 2534 2538 </p> 2535 2539 <div id="rfc.iref.73"></div> … … 2546 2550 </p> 2547 2551 </div> 2548 <p id="rfc.section.6.4.2.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1 1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 301 responses.2552 <p id="rfc.section.6.4.2.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 301 responses. 2549 2553 </p> 2550 2554 <div id="rfc.iref.73"></div> … … 2671 2675 any length of time — that is left to the discretion of the server owner. 2672 2676 </p> 2673 <p id="rfc.section.6.5.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1 2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 410 responses.2677 <p id="rfc.section.6.5.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 410 responses. 2674 2678 </p> 2675 2679 <div id="rfc.iref.74"></div> … … 2699 2703 <div id="rfc.iref.74"></div> 2700 2704 <h3 id="rfc.section.6.5.14"><a href="#rfc.section.6.5.14">6.5.14</a> <a id="status.417" href="#status.417">417 Expectation Failed</a></h3> 2701 <p id="rfc.section.6.5.14.p.1">The <dfn>417 (Expectation Failed)</dfn> status code indicates that the expectation given in the request's <a href="#header.expect" class="smpl">Expect</a> header field (<a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 5.1. 2</a>) could not be met by at least one of the inbound servers.2705 <p id="rfc.section.6.5.14.p.1">The <dfn>417 (Expectation Failed)</dfn> status code indicates that the expectation given in the request's <a href="#header.expect" class="smpl">Expect</a> header field (<a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section 5.1.1</a>) could not be met by at least one of the inbound servers. 2702 2706 </p> 2703 2707 <div id="rfc.iref.74"></div> … … 2765 2769 </p> 2766 2770 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="response.control.data" href="#response.control.data">Control Data</a></h2> 2767 <p id="rfc.section.7.1.p.1">Response header fields can supply control data that supplements the status code or instructs the client where to go next.</p> 2771 <p id="rfc.section.7.1.p.1">Response header fields can supply control data that supplements the status code, directs caching, or instructs the client 2772 where to go next. 2773 </p> 2768 2774 <div id="rfc.table.u.10"> 2769 2775 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 2777 2783 <tr> 2778 2784 <td class="left">Age</td> 2779 <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2785 <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2786 </tr> 2787 <tr> 2788 <td class="left">Cache-Control</td> 2789 <td class="left"><a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2790 </tr> 2791 <tr> 2792 <td class="left">Expires</td> 2793 <td class="left"><a href="p6-cache.html#header.expires" title="Expires">Section 7.3</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2780 2794 </tr> 2781 2795 <tr> … … 2790 2804 <td class="left">Retry-After</td> 2791 2805 <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section 7.1.3</a></td> 2806 </tr> 2807 <tr> 2808 <td class="left">Warning</td> 2809 <td class="left"><a href="p6-cache.html#header.warning" title="Warning">Section 7.5</a> of <a href="#Part6" id="rfc.xref.Part6.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td> 2792 2810 </tr> 2793 2811 </tbody> … … 3008 3026 not limited to those defined by this specification. 3009 3027 </p> 3010 <p id="rfc.section.7.2.1.p.5">An origin server might send Vary with a list of fields for two purposes: </p> 3028 <div id="rfc.figure.u.58"></div> 3029 <p>For example, a response that contains</p><pre class="text"> Vary: accept-encoding, accept-language 3030 </pre><p>indicates that the origin server might have used the request's <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> and <a href="#header.accept-language" class="smpl">Accept-Language</a> fields (or lack thereof) as determining factors while choosing this <a href="#selected.representation" class="smpl">selected representation</a>. 3031 </p> 3032 <p id="rfc.section.7.2.1.p.6">An origin server might send Vary with a list of fields for two purposes: </p> 3011 3033 <ol> 3012 3034 <li> 3013 3035 <p>To inform cache recipients that they <em class="bcp14">MUST NOT</em> use this response to satisfy a later request unless the later request has the same values for the listed fields as the original 3014 request (<a href="p6-cache.html#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.1 4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry.3036 request (<a href="p6-cache.html#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry. 3015 3037 </p> 3016 3038 </li> … … 3021 3043 </li> 3022 3044 </ol> 3023 <p id="rfc.section.7.2.1.p.6">Unless it has been deliberately configured to prevent cache transparency, an origin server <em class="bcp14">SHOULD</em> send a Vary header field in a cacheable response that is subject to proactive negotiation. 3024 </p> 3025 <div id="rfc.figure.u.58"></div> 3026 <p>For example, a response that contains</p><pre class="text"> Vary: accept-encoding, accept-language 3027 </pre><p>indicates that the origin server might have used the request's <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> and <a href="#header.accept-language" class="smpl">Accept-Language</a> fields (or lack thereof) as determining factors while choosing this <a href="#selected.representation" class="smpl">selected representation</a>. 3045 <p id="rfc.section.7.2.1.p.7">An origin server <em class="bcp14">SHOULD</em> send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message 3046 other than the method and request target, unless the variance cannot be crossed or the origin server has been deliberately 3047 configured to prevent cache transparency. For example, there is no need to send the Authorization field name (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>) in Vary because reuse across users is constrained by the field definition. Likewise, Cache-Control directives (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) might be used to supplant the need for Vary, particularly when the variance is considered less significant than the performance 3048 cost of Vary's impact on caching. 3028 3049 </p> 3029 3050 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="response.auth" href="#response.auth">Authentication Challenges</a></h2> … … 3042 3063 <tr> 3043 3064 <td class="left">WWW-Authenticate</td> 3044 <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7. 7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>3065 <td class="left"><a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 4.4</a> of <a href="#Part7" id="rfc.xref.Part7.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 3045 3066 </tr> 3046 3067 <tr> 3047 3068 <td class="left">Proxy-Authenticate</td> 3048 <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7. 8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td>3069 <td class="left"><a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 4.2</a> of <a href="#Part7" id="rfc.xref.Part7.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a></td> 3049 3070 </tr> 3050 3071 </tbody> … … 3240 3261 </p> 3241 3262 <p id="rfc.section.8.2.2.p.5">A response that can transfer a payload ought to specify expected cache behavior (e.g., cacheability and freshness criteria, 3242 as described in <a href="#Part6" id="rfc.xref.Part6. 15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>).3263 as described in <a href="#Part6" id="rfc.xref.Part6.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>). 3243 3264 </p> 3244 3265 <h3 id="rfc.section.8.2.3"><a href="#rfc.section.8.2.3">8.2.3</a> <a id="status.code.registration" href="#status.code.registration">Registrations</a></h3> … … 3536 3557 </li> 3537 3558 <li> 3538 <p>How the header field might interact with caching (see <a href="#Part6" id="rfc.xref.Part6. 16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).3559 <p>How the header field might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). 3539 3560 </p> 3540 3561 </li> … … 3635 3656 <td class="left">http</td> 3636 3657 <td class="left">standard</td> 3637 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 5.1. 2</a>3658 <td class="left"> <a href="#header.expect" id="rfc.xref.header.expect.3" title="Expect">Section 5.1.1</a> 3638 3659 </td> 3639 3660 </tr> … … 3663 3684 <td class="left">http</td> 3664 3685 <td class="left">standard</td> 3665 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 5.1. 1</a>3686 <td class="left"> <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.4" title="Max-Forwards">Section 5.1.2</a> 3666 3687 </td> 3667 3688 </tr> … … 4123 4144 </p> 4124 4145 <p id="rfc.section.B.p.11">The definition of <a href="#header.expect" class="smpl">Expect</a> has been both fixed to allow parameters for value-less expectations and simplified to allow trailing semicolons after "100-continue" 4125 (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 5.1. 2</a>).4126 </p> 4127 <p id="rfc.section.B.p.12">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 5.1. 1</a>) has been restricted to the <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> methods; previously, extension methods could have used it as well.4146 (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 5.1.1</a>). 4147 </p> 4148 <p id="rfc.section.B.p.12">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 5.1.2</a>) has been restricted to the <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> methods; previously, extension methods could have used it as well. 4128 4149 </p> 4129 4150 <p id="rfc.section.B.p.13">The "about:blank" URI has been suggested as a value for the <a href="#header.referer" class="smpl">Referer</a> header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not … … 4342 4363 <ul class="ind"> 4343 4364 <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul> 4344 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">5.1. 2.1</a>, <a href="#rfc.xref.status.100.2">5.1.2.1</a>, <a href="#rfc.xref.status.100.3">6.1</a>, <a href="#rfc.iref.71"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.4">8.2.3</a></li>4345 <li>100-continue (expect value) <a href="#rfc.iref.4 6"><b>5.1.2.1</b></a></li>4365 <li>100 Continue (status code) <a href="#rfc.xref.status.100.1">5.1.1.1</a>, <a href="#rfc.xref.status.100.2">5.1.1.1</a>, <a href="#rfc.xref.status.100.3">6.1</a>, <a href="#rfc.iref.71"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.4">8.2.3</a></li> 4366 <li>100-continue (expect value) <a href="#rfc.iref.44"><b>5.1.1.1</b></a></li> 4346 4367 <li>101 Switching Protocols (status code) <a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.71"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">8.2.3</a></li> 4347 4368 <li>1xx Informational (status code class) <a href="#rfc.iref.70"><b>6.2</b></a></li> … … 4431 4452 </li> 4432 4453 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 4433 <li>Expect header field <a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1. 2</b></a>, <a href="#rfc.xref.header.expect.2">6.5.14</a>, <a href="#rfc.xref.header.expect.3">8.3.2</a>, <a href="#rfc.xref.header.expect.4">B</a></li>4454 <li>Expect header field <a href="#rfc.xref.header.expect.1">5.1</a>, <a href="#rfc.iref.e.1"><b>5.1.1</b></a>, <a href="#rfc.xref.header.expect.2">6.5.14</a>, <a href="#rfc.xref.header.expect.3">8.3.2</a>, <a href="#rfc.xref.header.expect.4">B</a></li> 4434 4455 <li>Expect Values 4435 4456 <ul> 4436 <li>100-continue <a href="#rfc.iref.e.2"><b>5.1. 2.1</b></a></li>4457 <li>100-continue <a href="#rfc.iref.e.2"><b>5.1.1.1</b></a></li> 4437 4458 </ul> 4438 4459 </li> … … 4469 4490 <li><tt>day-name-l</tt> <a href="#rfc.iref.g.47"><b>7.1.1.1</b></a></li> 4470 4491 <li><tt>delta-seconds</tt> <a href="#rfc.iref.g.58"><b>7.1.3</b></a></li> 4471 <li><tt>Expect</tt> <a href="#rfc.iref.g.1 8"><b>5.1.2</b></a></li>4472 <li><tt>expect-name</tt> <a href="#rfc.iref.g.2 2"><b>5.1.2</b></a></li>4473 <li><tt>expect-param</tt> <a href="#rfc.iref.g. 20"><b>5.1.2</b></a></li>4474 <li><tt>expect-value</tt> <a href="#rfc.iref.g.2 1"><b>5.1.2</b></a></li>4475 <li><tt>expectation</tt> <a href="#rfc.iref.g.1 9"><b>5.1.2</b></a></li>4492 <li><tt>Expect</tt> <a href="#rfc.iref.g.17"><b>5.1.1</b></a></li> 4493 <li><tt>expect-name</tt> <a href="#rfc.iref.g.21"><b>5.1.1</b></a></li> 4494 <li><tt>expect-param</tt> <a href="#rfc.iref.g.19"><b>5.1.1</b></a></li> 4495 <li><tt>expect-value</tt> <a href="#rfc.iref.g.20"><b>5.1.1</b></a></li> 4496 <li><tt>expectation</tt> <a href="#rfc.iref.g.18"><b>5.1.1</b></a></li> 4476 4497 <li><tt>From</tt> <a href="#rfc.iref.g.34"><b>5.5.1</b></a></li> 4477 4498 <li><tt>GMT</tt> <a href="#rfc.iref.g.51"><b>7.1.1.1</b></a></li> … … 4482 4503 <li><tt>language-tag</tt> <a href="#rfc.iref.g.12"><b>3.1.3.1</b></a></li> 4483 4504 <li><tt>Location</tt> <a href="#rfc.iref.g.56"><b>7.1.2</b></a></li> 4484 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g. 17"><b>5.1.1</b></a></li>4505 <li><tt>Max-Forwards</tt> <a href="#rfc.iref.g.22"><b>5.1.2</b></a></li> 4485 4506 <li><tt>media-range</tt> <a href="#rfc.iref.g.26"><b>5.3.2</b></a></li> 4486 4507 <li><tt>media-type</tt> <a href="#rfc.iref.g.1"><b>3.1.1.1</b></a></li> … … 4524 4545 </li> 4525 4546 <li><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul> 4526 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.1</a>, <a href="#rfc.iref.m.1"><b>5.1. 1</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">B</a></li>4547 <li>Max-Forwards header field <a href="#rfc.xref.header.max-forwards.1">4.3.7</a>, <a href="#rfc.xref.header.max-forwards.2">4.3.8</a>, <a href="#rfc.xref.header.max-forwards.3">5.1</a>, <a href="#rfc.iref.m.1"><b>5.1.2</b></a>, <a href="#rfc.xref.header.max-forwards.4">8.3.2</a>, <a href="#rfc.xref.header.max-forwards.5">B</a></li> 4527 4548 <li>MIME-Version header field <a href="#rfc.xref.mime-version.1">8.3.2</a>, <a href="#rfc.iref.m.2"><b>A.1</b></a></li> 4528 4549 </ul> 4529 4550 </li> 4530 4551 <li><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul> 4531 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1. 1</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.13">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.14">B</a></li>4552 <li>OPTIONS method <a href="#rfc.xref.OPTIONS.1">4.1</a>, <a href="#rfc.iref.o.1"><b>4.3.7</b></a>, <a href="#rfc.xref.OPTIONS.2">5.1.2</a>, <a href="#rfc.xref.OPTIONS.3">8.1.3</a>, <a href="#rfc.extref.o.13">B</a>, <a href="#rfc.xref.OPTIONS.4">B</a>, <a href="#rfc.extref.o.14">B</a></li> 4532 4553 </ul> 4533 4554 </li> 4534 4555 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 4535 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5. 5</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">B</a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a><ul>4556 <li><em>Part1</em> <a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.2.1</a>, <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.10">3.1.2.2</a>, <a href="#rfc.xref.Part1.11">3.1.4.1</a>, <a href="#rfc.xref.Part1.12">3.1.4.2</a>, <a href="#rfc.xref.Part1.13">3.3</a>, <a href="#rfc.xref.Part1.14">3.3</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.17">4.3.8</a>, <a href="#rfc.xref.Part1.18">4.3.8</a>, <a href="#rfc.xref.Part1.19">5.1</a>, <a href="#rfc.xref.Part1.20">5.1</a>, <a href="#rfc.xref.Part1.21">5.5.3</a>, <a href="#rfc.xref.Part1.22">6.2.2</a>, <a href="#rfc.xref.Part1.23">6.3.4</a>, <a href="#rfc.xref.Part1.24">6.5.7</a>, <a href="#rfc.xref.Part1.25">6.5.10</a>, <a href="#rfc.xref.Part1.26">6.5.12</a>, <a href="#rfc.xref.Part1.27">6.5.15</a>, <a href="#rfc.xref.Part1.28">6.6.6</a>, <a href="#rfc.xref.Part1.29">7.4.2</a>, <a href="#rfc.xref.Part1.30">8.1.2</a>, <a href="#rfc.xref.Part1.31">8.3.1</a>, <a href="#rfc.xref.Part1.32">8.3.1</a>, <a href="#rfc.xref.Part1.33">8.3.1</a>, <a href="#rfc.xref.Part1.34">8.3.1</a>, <a href="#rfc.xref.Part1.35">8.3.1</a>, <a href="#rfc.xref.Part1.36">8.3.1</a>, <a href="#rfc.xref.Part1.37">8.4</a>, <a href="#rfc.xref.Part1.38">8.4.1</a>, <a href="#rfc.xref.Part1.39">8.4.1</a>, <a href="#rfc.xref.Part1.40">8.4.2</a>, <a href="#rfc.xref.Part1.41">8.4.2</a>, <a href="#rfc.xref.Part1.42">8.4.2</a>, <a href="#rfc.xref.Part1.43">9.4</a>, <a href="#rfc.xref.Part1.44">10</a>, <a href="#Part1"><b>11.1</b></a>, <a href="#rfc.xref.Part1.45">B</a>, <a href="#rfc.xref.Part1.46">C</a>, <a href="#rfc.xref.Part1.47">C</a>, <a href="#rfc.xref.Part1.48">C</a>, <a href="#rfc.xref.Part1.49">C</a>, <a href="#rfc.xref.Part1.50">C</a>, <a href="#rfc.xref.Part1.51">C</a>, <a href="#rfc.xref.Part1.52">C</a>, <a href="#rfc.xref.Part1.53">C</a>, <a href="#rfc.xref.Part1.54">C</a>, <a href="#rfc.xref.Part1.55">C</a>, <a href="#rfc.xref.Part1.56">C</a>, <a href="#rfc.xref.Part1.57">C</a><ul> 4536 4557 <li><em>Section 1.2</em> <a href="#rfc.xref.Part1.3">1.2</a></li> 4537 4558 <li><em>Section 2.5</em> <a href="#rfc.xref.Part1.2">1.1</a></li> … … 4550 4571 <li><em>Section 4.2.2</em> <a href="#rfc.xref.Part1.8">3.1.2.1</a>, <a href="#rfc.xref.Part1.41">8.4.2</a></li> 4551 4572 <li><em>Section 4.2.3</em> <a href="#rfc.xref.Part1.9">3.1.2.1</a>, <a href="#rfc.xref.Part1.42">8.4.2</a></li> 4552 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">5. 5</a></li>4573 <li><em>Section 4.3</em> <a href="#rfc.xref.Part1.20">5.1</a></li> 4553 4574 <li><em>Section 5.3</em> <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.15">4.3.6</a>, <a href="#rfc.xref.Part1.16">4.3.7</a>, <a href="#rfc.xref.Part1.26">6.5.12</a></li> 4554 4575 <li><em>Section 5.4</em> <a href="#rfc.xref.Part1.19">5.1</a></li> … … 4586 4607 </ul> 4587 4608 </li> 4588 <li><em>Part6</em> <a href="#rfc.xref.Part6.1"> 3.1</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.9">6.3.4</a>, <a href="#rfc.xref.Part6.10">6.4.1</a>, <a href="#rfc.xref.Part6.11">6.4.2</a>, <a href="#rfc.xref.Part6.12">6.5.9</a>, <a href="#rfc.xref.Part6.13">7.1</a>, <a href="#rfc.xref.Part6.14">7.2.1</a>, <a href="#rfc.xref.Part6.15">8.2.2</a>, <a href="#rfc.xref.Part6.16">8.3.1</a>, <a href="#Part6"><b>11.1</b></a><ul>4609 <li><em>Part6</em> <a href="#rfc.xref.Part6.1">4.2.3</a>, <a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.9">5.1</a>, <a href="#rfc.xref.Part6.10">6.3.1</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a>, <a href="#rfc.xref.Part6.15">7.1</a>, <a href="#rfc.xref.Part6.16">7.1</a>, <a href="#rfc.xref.Part6.17">7.1</a>, <a href="#rfc.xref.Part6.18">7.1</a>, <a href="#rfc.xref.Part6.19">7.2.1</a>, <a href="#rfc.xref.Part6.20">7.2.1</a>, <a href="#rfc.xref.Part6.21">8.2.2</a>, <a href="#rfc.xref.Part6.22">8.3.1</a>, <a href="#Part6"><b>11.1</b></a><ul> 4589 4610 <li><em>Section 4.1.1</em> <a href="#rfc.xref.Part6.5">4.3.3</a></li> 4590 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part6. 8">6.3.1</a>, <a href="#rfc.xref.Part6.10">6.4.1</a>, <a href="#rfc.xref.Part6.11">6.4.2</a>, <a href="#rfc.xref.Part6.12">6.5.9</a></li>4591 <li><em>Section 4.3</em> <a href="#rfc.xref.Part6.1 4">7.2.1</a></li>4611 <li><em>Section 4.1.2</em> <a href="#rfc.xref.Part6.10">6.3.1</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a></li> 4612 <li><em>Section 4.3</em> <a href="#rfc.xref.Part6.19">7.2.1</a></li> 4592 4613 <li><em>Section 5</em> <a href="#rfc.xref.Part6.4">4.3.2</a></li> 4593 4614 <li><em>Section 6</em> <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a></li> 4594 <li><em>Section 7.1</em> <a href="#rfc.xref.Part6.13">7.1</a></li> 4595 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.1">3.1</a></li> 4596 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.9">6.3.4</a></li> 4615 <li><em>Section 7.1</em> <a href="#rfc.xref.Part6.15">7.1</a></li> 4616 <li><em>Section 7.2</em> <a href="#rfc.xref.Part6.2">4.3.1</a>, <a href="#rfc.xref.Part6.3">4.3.2</a>, <a href="#rfc.xref.Part6.8">5.1</a>, <a href="#rfc.xref.Part6.16">7.1</a>, <a href="#rfc.xref.Part6.20">7.2.1</a></li> 4617 <li><em>Section 7.3</em> <a href="#rfc.xref.Part6.17">7.1</a></li> 4618 <li><em>Section 7.4</em> <a href="#rfc.xref.Part6.9">5.1</a></li> 4619 <li><em>Section 7.5</em> <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.18">7.1</a></li> 4597 4620 </ul> 4598 4621 </li> 4599 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">4.3.8</a>, <a href="#rfc.xref.Part7.2">5.4</a>, <a href="#rfc.xref.Part7.3">5.4</a>, <a href="#rfc.xref.Part7.4">6.1</a>, <a href="#rfc.xref.Part7.5">6.1</a>, <a href="#rfc.xref.Part7.6">6.1</a>, <a href="#rfc.xref.Part7.7">7. 3</a>, <a href="#rfc.xref.Part7.8">7.3</a>, <a href="#Part7"><b>11.1</b></a><ul>4622 <li><em>Part7</em> <a href="#rfc.xref.Part7.1">4.3.8</a>, <a href="#rfc.xref.Part7.2">5.4</a>, <a href="#rfc.xref.Part7.3">5.4</a>, <a href="#rfc.xref.Part7.4">6.1</a>, <a href="#rfc.xref.Part7.5">6.1</a>, <a href="#rfc.xref.Part7.6">6.1</a>, <a href="#rfc.xref.Part7.7">7.2.1</a>, <a href="#rfc.xref.Part7.8">7.3</a>, <a href="#rfc.xref.Part7.9">7.3</a>, <a href="#Part7"><b>11.1</b></a><ul> 4600 4623 <li><em>Section 3</em> <a href="#rfc.xref.Part7.4">6.1</a></li> 4601 4624 <li><em>Section 3.1</em> <a href="#rfc.xref.Part7.5">6.1</a></li> 4602 4625 <li><em>Section 3.2</em> <a href="#rfc.xref.Part7.6">6.1</a></li> 4603 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.2">5.4</a> </li>4604 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7. 8">7.3</a></li>4626 <li><em>Section 4.1</em> <a href="#rfc.xref.Part7.2">5.4</a>, <a href="#rfc.xref.Part7.7">7.2.1</a></li> 4627 <li><em>Section 4.2</em> <a href="#rfc.xref.Part7.9">7.3</a></li> 4605 4628 <li><em>Section 4.3</em> <a href="#rfc.xref.Part7.3">5.4</a></li> 4606 <li><em>Section 4.4</em> <a href="#rfc.xref.Part7. 7">7.3</a></li>4629 <li><em>Section 4.4</em> <a href="#rfc.xref.Part7.8">7.3</a></li> 4607 4630 </ul> 4608 4631 </li> … … 4635 4658 </ul> 4636 4659 </li> 4637 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">5.1. 2.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul>4660 <li><em>RFC2068</em> <a href="#rfc.xref.RFC2068.1">5.1.1.1</a>, <a href="#rfc.xref.RFC2068.2">6.4</a>, <a href="#RFC2068"><b>11.2</b></a><ul> 4638 4661 <li><em>Section 10.3</em> <a href="#rfc.xref.RFC2068.2">6.4</a></li> 4639 4662 </ul> … … 4709 4732 </li> 4710 4733 <li><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul> 4711 <li>TRACE method <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1. 1</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">B</a>, <a href="#rfc.xref.TRACE.4">B</a>, <a href="#rfc.extref.t.51">B</a></li>4734 <li>TRACE method <a href="#rfc.xref.TRACE.1">4.1</a>, <a href="#rfc.iref.t.1"><b>4.3.8</b></a>, <a href="#rfc.xref.TRACE.2">5.1.2</a>, <a href="#rfc.xref.TRACE.3">8.1.3</a>, <a href="#rfc.extref.t.50">B</a>, <a href="#rfc.xref.TRACE.4">B</a>, <a href="#rfc.extref.t.51">B</a></li> 4712 4735 </ul> 4713 4736 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2091 r2092 325 325 <c>Content-Language</c> <c><xref target="header.content-language"/></c> 326 326 <c>Content-Location</c> <c><xref target="header.content-location"/></c> 327 <c>Expires</c> <c>&header-expires;</c>328 327 </texttable> 329 328 … … 1265 1264 </t> 1266 1265 <t> 1266 The response to a GET request is cacheable; a cache &MAY; use it to satisfy 1267 subsequent GET and HEAD requests unless otherwise indicated by the 1268 Cache-Control header field (&header-cache-control;). 1269 </t> 1270 <t> 1267 1271 A payload within a GET request message has no defined semantics; 1268 1272 sending a payload body on a GET request might cause some existing 1269 1273 implementations to reject the request. 1270 </t>1271 <t>1272 The response to a GET request is cacheable and &MAY; be used to satisfy1273 subsequent GET and HEAD requests (see &caching;).1274 1274 </t> 1275 1275 </section> … … 1284 1284 The HEAD method is identical to GET except that the server &MUST-NOT; 1285 1285 send a message body in the response (i.e., the response terminates at the 1286 end of the header block). The metadata contained in the HTTP header fields 1287 in response to a HEAD request &SHOULD; be identical to the information sent 1288 in response to a GET request. This method can be used for obtaining 1289 metadata about the selected representation without transferring the 1290 representation data. This method is often used for testing hypertext links 1291 for validity, accessibility, and recent modification. 1292 </t> 1293 <t> 1294 The response to a HEAD request is cacheable and &MAY; be used to satisfy 1295 a subsequent HEAD request. It also has potential side effects on 1296 previously stored responses to GET; see &p6-head;. 1286 end of the header block). Aside from the payload header fields 1287 (<xref target="payload"/>), the server &SHOULD; send the same header fields 1288 in response to a HEAD request as it would have sent if the request had been 1289 a GET. This method can be used for obtaining metadata about the selected 1290 representation without transferring the representation data. This method is 1291 often used for testing hypertext links for validity, accessibility, and 1292 recent modification. 1293 </t> 1294 <t> 1295 The response to a HEAD request is cacheable; a cache &MAY; use it to 1296 satisfy subsequent HEAD requests unless otherwise indicated by the 1297 Cache-Control header field (&header-cache-control;). A HEAD response might 1298 also have an effect on previously cached responses to GET; see &p6-head;. 1297 1299 </t> 1298 1300 <t> … … 1734 1736 <ttcol>Defined in...</ttcol> 1735 1737 1738 <c>Cache-Control</c> <c>&header-cache-control;</c> 1739 <c>Expect</c> <c><xref target="header.expect"/></c> 1736 1740 <c>Host</c> <c>&header-host;</c> 1737 1741 <c>Max-Forwards</c> <c><xref target="header.max-forwards"/></c> 1738 <c> Expect</c> <c><xref target="header.expect"/></c>1742 <c>Pragma</c> <c>&header-pragma;</c> 1739 1743 <c>Range</c> <c>&header-range;</c> 1744 <c>TE</c> <c>&header-te;</c> 1740 1745 </texttable> 1741 1742 <section title="Max-Forwards" anchor="header.max-forwards">1743 <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/>1744 <x:anchor-alias value="Max-Forwards"/>1745 <t>1746 The "Max-Forwards" header field provides a mechanism with the1747 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)1748 methods to limit the number of times that the request is forwarded by1749 proxies. This can be useful when the client is attempting to1750 trace a request that appears to be failing or looping mid-chain.1751 </t>1752 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>1753 <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>1754 </artwork></figure>1755 <t>1756 The Max-Forwards value is a decimal integer indicating the remaining1757 number of times this request message can be forwarded.1758 </t>1759 <t>1760 Each recipient of a TRACE or OPTIONS request1761 containing a Max-Forwards header field &MUST; check and update its1762 value prior to forwarding the request. If the received value is zero1763 (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;1764 respond as the final recipient. If the received Max-Forwards value is1765 greater than zero, then the forwarded message &MUST; contain an updated1766 Max-Forwards field with a value decremented by one (1).1767 </t>1768 <t>1769 The Max-Forwards header field &MAY; be ignored for all other request1770 methods.1771 </t>1772 </section>1773 1746 1774 1747 <section title="Expect" anchor="header.expect"> … … 1943 1916 </section> 1944 1917 </section> 1918 1919 <section title="Max-Forwards" anchor="header.max-forwards"> 1920 <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/> 1921 <x:anchor-alias value="Max-Forwards"/> 1922 <t> 1923 The "Max-Forwards" header field provides a mechanism with the 1924 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) 1925 methods to limit the number of times that the request is forwarded by 1926 proxies. This can be useful when the client is attempting to 1927 trace a request that appears to be failing or looping mid-chain. 1928 </t> 1929 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/> 1930 <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref> 1931 </artwork></figure> 1932 <t> 1933 The Max-Forwards value is a decimal integer indicating the remaining 1934 number of times this request message can be forwarded. 1935 </t> 1936 <t> 1937 Each recipient of a TRACE or OPTIONS request 1938 containing a Max-Forwards header field &MUST; check and update its 1939 value prior to forwarding the request. If the received value is zero 1940 (0), the recipient &MUST-NOT; forward the request; instead, it &MUST; 1941 respond as the final recipient. If the received Max-Forwards value is 1942 greater than zero, then the forwarded message &MUST; contain an updated 1943 Max-Forwards field with a value decremented by one (1). 1944 </t> 1945 <t> 1946 The Max-Forwards header field &MAY; be ignored for all other request 1947 methods. 1948 </t> 1949 </section> 1945 1950 </section> 1946 1951 … … 2335 2340 <c>From</c> <c><xref target="header.from"/></c> 2336 2341 <c>Referer</c> <c><xref target="header.referer"/></c> 2337 <c>TE</c> <c>&header-te;</c>2338 2342 <c>User-Agent</c> <c><xref target="header.user-agent"/></c> 2339 2343 </texttable> … … 3502 3506 <t> 3503 3507 Response header fields can supply control data that supplements the 3504 status code or instructs the client where to go next.3508 status code, directs caching, or instructs the client where to go next. 3505 3509 </t> 3506 3510 <texttable align="left"> … … 3508 3512 3509 3513 <c>Age</c> <c>&header-age;</c> 3514 <c>Cache-Control</c> <c>&header-cache-control;</c> 3515 <c>Expires</c> <c>&header-expires;</c> 3510 3516 <c>Date</c> <c><xref target="header.date"/></c> 3511 3517 <c>Location</c> <c><xref target="header.location"/></c> 3512 3518 <c>Retry-After</c> <c><xref target="header.retry-after"/></c> 3519 <c>Warning</c> <c>&header-warning;</c> 3513 3520 </texttable> 3514 3521 … … 3882 3889 header fields are not limited to those defined by this specification. 3883 3890 </t> 3891 <figure><preamble>For example, a response that contains</preamble><artwork type="example"> 3892 Vary: accept-encoding, accept-language 3893 </artwork><postamble>indicates that the origin server might have used the 3894 request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref> 3895 fields (or lack thereof) as determining factors while choosing this 3896 <x:ref>selected representation</x:ref>. 3897 </postamble></figure> 3884 3898 <t> 3885 3899 An origin server might send Vary with a list of fields for two purposes: … … 3906 3920 </t> 3907 3921 <t> 3908 Unless it has been deliberately configured to prevent cache transparency, 3909 an origin server &SHOULD; send a Vary header field in a cacheable 3910 response that is subject to proactive negotiation. 3911 </t> 3912 <figure><preamble>For example, a response that contains</preamble><artwork type="example"> 3913 Vary: accept-encoding, accept-language 3914 </artwork><postamble>indicates that the origin server might have used the 3915 request's <x:ref>Accept-Encoding</x:ref> and <x:ref>Accept-Language</x:ref> 3916 fields (or lack thereof) as determining factors while choosing this 3917 <x:ref>selected representation</x:ref>.</postamble></figure> 3922 An origin server &SHOULD; send a Vary header field when its algorithm for 3923 selecting a representation varies based on aspects of the request message 3924 other than the method and request target, unless the variance cannot be 3925 crossed or the origin server has been deliberately configured to prevent 3926 cache transparency. For example, there is no need to send the 3927 Authorization field name (&header-authorization;) in Vary because 3928 reuse across users is constrained by the field definition. Likewise, 3929 Cache-Control directives (&header-cache-control;) might be used to supplant 3930 the need for Vary, particularly when the variance is considered less 3931 significant than the performance cost of Vary's impact on caching. 3932 </t> 3918 3933 </section> 3919 3934 </section>
Note: See TracChangeset
for help on using the changeset viewer.