![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 195
- Timestamp:
- 05/02/08 00:16:12 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p2-semantics.html (modified) (10 diffs)
-
p2-semantics.xml (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r190 r195 756 756 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> 757 757 <p id="rfc.section.7.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed 758 to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="p1-messaging.html#header.host" title="Host">Section 8.4</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>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.758 to share the same semantics for separately extended clients and servers. 759 759 </p> 760 760 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2> … … 915 915 </p> 916 916 <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 917 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. 6"><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 the917 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 918 918 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 919 919 infinite loop. … … 948 948 <p id="rfc.section.8.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 949 949 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 950 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. 7"><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.950 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. 951 951 </p> 952 952 <div id="rfc.iref.24"></div> … … 1330 1330 <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1331 1331 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1332 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</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>, 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.1332 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. 1333 1333 </p> 1334 1334 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1377 1377 </p> 1378 1378 <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p> 1379 <p id="rfc.section.9.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. 9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.1379 <p id="rfc.section.9.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. 1380 1380 </p> 1381 1381 <div id="rfc.iref.f.1"></div> … … 1466 1466 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1467 1467 <p id="rfc.section.9.8.p.1">The Server response-header field contains information about the software used by the origin server to handle the request. 1468 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</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>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance1468 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</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>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance 1469 1469 for identifying the application. 1470 1470 </p> … … 1472 1472 </pre><p id="rfc.section.9.8.p.3">Example:</p> 1473 1473 <div id="rfc.figure.u.18"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1474 </pre><p id="rfc.section.9.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.1 1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).1474 </pre><p id="rfc.section.9.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.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1475 1475 </p> 1476 1476 <dl class="empty"> … … 1485 1485 <p id="rfc.section.9.9.p.1">The User-Agent request-header field contains information about the user agent originating the request. This is for statistical 1486 1486 purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses 1487 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</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>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the1487 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.5</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>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the 1488 1488 product tokens are listed in order of their significance for identifying the application. 1489 1489 </p> … … 1665 1665 </p> 1666 1666 <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 1667 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 3"><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 9.8</a>)1667 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.12"><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 9.8</a>) 1668 1668 </p> 1669 1669 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> Change Log (to be removed by RFC Editor before publication) … … 1893 1893 </li> 1894 1894 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1895 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">3</a>, <a class="iref" href="#rfc.xref.Part1.3">3</a>, <a class="iref" href="#rfc.xref.Part1.4">6</a>, <a class="iref" href="#rfc.xref.Part1.5">7 </a>, <a class="iref" href="#rfc.xref.Part1.6">7.8</a>, <a class="iref" href="#rfc.xref.Part1.7">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.9">9.2</a>, <a class="iref" href="#rfc.xref.Part1.10">9.8</a>, <a class="iref" href="#rfc.xref.Part1.11">9.8</a>, <a class="iref" href="#rfc.xref.Part1.12">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.13">A.2</a><ul class="ind">1896 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1. 8">8.5.6</a></li>1897 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part1. 10">9.8</a>, <a class="iref" href="#rfc.xref.Part1.12">9.9</a></li>1895 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">3</a>, <a class="iref" href="#rfc.xref.Part1.3">3</a>, <a class="iref" href="#rfc.xref.Part1.4">6</a>, <a class="iref" href="#rfc.xref.Part1.5">7.8</a>, <a class="iref" href="#rfc.xref.Part1.6">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.7">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.8">9.2</a>, <a class="iref" href="#rfc.xref.Part1.9">9.8</a>, <a class="iref" href="#rfc.xref.Part1.10">9.8</a>, <a class="iref" href="#rfc.xref.Part1.11">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.12">A.2</a><ul class="ind"> 1896 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.7">8.5.6</a></li> 1897 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part1.9">9.8</a>, <a class="iref" href="#rfc.xref.Part1.11">9.9</a></li> 1898 1898 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.4">6</a></li> 1899 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1. 7">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.9">9.2</a></li>1900 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.2">3</a> , <a class="iref" href="#rfc.xref.Part1.5">7</a></li>1899 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.6">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">9.2</a></li> 1900 <li class="indline1"><em>Section 8.4</em> <a class="iref" href="#rfc.xref.Part1.2">3</a></li> 1901 1901 <li class="indline1"><em>Section 8.8</em> <a class="iref" href="#rfc.xref.Part1.3">3</a></li> 1902 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1. 6">7.8</a>, <a class="iref" href="#rfc.xref.Part1.11">9.8</a>, <a class="iref" href="#rfc.xref.Part1.13">A.2</a></li>1902 <li class="indline1"><em>Section 8.9</em> <a class="iref" href="#rfc.xref.Part1.5">7.8</a>, <a class="iref" href="#rfc.xref.Part1.10">9.8</a>, <a class="iref" href="#rfc.xref.Part1.12">A.2</a></li> 1903 1903 </ul> 1904 1904 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r190 r195 487 487 this set can be expanded, additional methods cannot be assumed to 488 488 share the same semantics for separately extended clients and servers. 489 490 The Host request-header field (&header-host;) &MUST; accompany all491 HTTP/1.1 requests.492 489 </t> 493 490
Note: See TracChangeset
for help on using the changeset viewer.
