![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 130 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 01/01/08 14:14:28 (13 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p2-semantics.html (modified) (10 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r129 r130 880 880 However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. 881 881 </p> 882 <p id="rfc.section.8.5.p.6">POST requests <em class="bcp14">MUST</em> obey the message transmission requirements set out in <a href="p1-messaging.html#message.transmission.requirements" title="Message Transmission Requirements">Section 7.2</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.883 </p>884 <p id="rfc.section.8.5.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section 12.2</a> for security considerations.885 </p>886 882 <div id="rfc.iref.p.2"></div> 887 883 <div id="rfc.iref.m.5"></div> … … 907 903 </p> 908 904 <p id="rfc.section.8.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> 909 <p id="rfc.section.8.6.p.6">PUT requests <em class="bcp14">MUST</em> obey the message transmission requirements set out in <a href="p1-messaging.html#message.transmission.requirements" title="Message Transmission Requirements">Section 7.2</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 910 </p> 911 <p id="rfc.section.8.6.p.7">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. 905 <p id="rfc.section.8.6.p.6">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. 912 906 </p> 913 907 <div id="rfc.iref.d.1"></div> … … 932 926 </p> 933 927 <p id="rfc.section.8.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 934 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1. 7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the928 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the 935 929 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 936 930 infinite loop. … … 965 959 <p id="rfc.section.9.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been 966 960 received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The 967 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1. 8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.961 server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code. 968 962 </p> 969 963 <div id="rfc.iref.26"></div> … … 1347 1341 <p id="rfc.section.9.5.6.p.1">The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server 1348 1342 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1349 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.1343 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server. 1350 1344 </p> 1351 1345 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1394 1388 </p> 1395 1389 <p id="rfc.section.10.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p> 1396 <p id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1. 10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (continue) status.1390 <p id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (continue) status. 1397 1391 </p> 1398 1392 <div id="rfc.iref.f.1"></div> … … 1489 1483 </pre><p id="rfc.section.10.8.p.3">Example:</p> 1490 1484 <div id="rfc.figure.u.20"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1491 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1. 11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1485 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1492 1486 </p> 1493 1487 <dl class="empty"> … … 1687 1681 </p> 1688 1682 <p id="rfc.section.A.2.p.4">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 1689 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.1 2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.8</a>)1683 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.8</a>) 1690 1684 </p> 1691 1685 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) … … 1710 1704 </li> 1711 1705 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65</a>>: "Informative references" 1706 </li> 1707 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84</a>>: "Redundant cross-references" 1712 1708 </li> 1713 1709 </ul> … … 1902 1898 </li> 1903 1899 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1904 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">4</a>, <a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.3">7</a>, <a class="iref" href="#rfc.xref.Part1.4">8</a>, <a class="iref" href="#rfc.xref.Part1.5">8. 5</a>, <a class="iref" href="#rfc.xref.Part1.6">8.6</a>, <a class="iref" href="#rfc.xref.Part1.7">8.8</a>, <a class="iref" href="#rfc.xref.Part1.8">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.9">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.10">10.2</a>, <a class="iref" href="#rfc.xref.Part1.11">10.8</a>, <a class="iref" href="#Part1"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part1.12">A.2</a><ul class="ind">1905 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1. 9">9.5.6</a></li>1900 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">4</a>, <a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.3">7</a>, <a class="iref" href="#rfc.xref.Part1.4">8</a>, <a class="iref" href="#rfc.xref.Part1.5">8.8</a>, <a class="iref" href="#rfc.xref.Part1.6">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.7">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.8">10.2</a>, <a class="iref" href="#rfc.xref.Part1.9">10.8</a>, <a class="iref" href="#Part1"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part1.10">A.2</a><ul class="ind"> 1901 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.7">9.5.6</a></li> 1906 1902 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.3">7</a></li> 1907 <li class="indline1"><em>Section 7.2</em> <a class="iref" href="#rfc.xref.Part1.5">8.5</a>, <a class="iref" href="#rfc.xref.Part1.6">8.6</a></li> 1908 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.8">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.10">10.2</a></li> 1903 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.6">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">10.2</a></li> 1909 1904 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.1">4</a>, <a class="iref" href="#rfc.xref.Part1.4">8</a></li> 1910 1905 <li class="indline1"><em>Section 8.8</em> <a class="iref" href="#rfc.xref.Part1.2">4</a></li> 1911 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1. 7">8.8</a>, <a class="iref" href="#rfc.xref.Part1.11">10.8</a>, <a class="iref" href="#rfc.xref.Part1.12">A.2</a></li>1906 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.5">8.8</a>, <a class="iref" href="#rfc.xref.Part1.9">10.8</a>, <a class="iref" href="#rfc.xref.Part1.10">A.2</a></li> 1912 1907 </ul> 1913 1908 </li>
Note: See TracChangeset
for help on using the changeset viewer.
