Changeset 403
- Timestamp:
- 15/11/08 20:16:54 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r402 r403 1334 1334 URI, it <em class="bcp14">MUST</em> be given as "/" (the server root). 1335 1335 </p> 1336 <p id="rfc.section.5.1.2.p.12">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.1.1</a>. If the request-target is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1337 </p> 1338 <p id="rfc.section.5.1.2.p.13">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted 1336 <p id="rfc.section.5.1.2.p.12">If a proxy receives a request without any path in the request-target and the method specified is capable of supporting the 1337 asterisk form of request-target, then the last proxy on the request chain <em class="bcp14">MUST</em> forward the request with "*" as the final request-target. 1338 </p> 1339 <div id="rfc.figure.u.40"></div> 1340 <p>For example, the request</p><pre class="text"> OPTIONS http://www.example.org:8001 HTTP/1.1 1341 </pre><div id="rfc.figure.u.41"></div> 1342 <p>would be forwarded by the proxy as</p><pre class="text"> OPTIONS * HTTP/1.1 1343 Host: www.example.org:8001 1344 </pre> <p>after connecting to port 8001 of host "www.example.org".</p> 1345 <p id="rfc.section.5.1.2.p.15">The request-target is transmitted in the format specified in <a href="#http.uri" title="http URI scheme">Section 2.1.1</a>. If the request-target is encoded using the "% <a href="#core.rules" class="smpl">HEXDIG</a> <a href="#core.rules" class="smpl">HEXDIG</a>" encoding (<a href="#RFC3986" id="rfc.xref.RFC3986.17"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-2.4">Section 2.4</a>), the origin server <em class="bcp14">MUST</em> decode the request-target in order to properly interpret the request. Servers <em class="bcp14">SHOULD</em> respond to invalid request-targets with an appropriate status code. 1346 </p> 1347 <p id="rfc.section.5.1.2.p.16">A transparent proxy <em class="bcp14">MUST NOT</em> rewrite the "path-absolute" part of the received request-target when forwarding it to the next inbound server, except as noted 1339 1348 above to replace a null path-absolute with "/". 1340 1349 </p> 1341 <p id="rfc.section.5.1.2.p.1 4"> </p>1350 <p id="rfc.section.5.1.2.p.17"> </p> 1342 1351 <dl class="empty"> 1343 1352 <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using … … 1346 1355 </dd> 1347 1356 </dl> 1348 <p id="rfc.section.5.1.2.p.1 5">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI too long) status if the received request-target1357 <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI too long) status if the received request-target 1349 1358 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1350 1359 </p> 1351 <p id="rfc.section.5.1.2.p.1 6">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.1360 <p id="rfc.section.5.1.2.p.19">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs. 1352 1361 </p> 1353 1362 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> … … 1374 1383 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="response" href="#response">Response</a></h1> 1375 1384 <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 1376 <div id="rfc.figure.u.4 0"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 6.1</a>1385 <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.77"></span> <a href="#response" class="smpl">Response</a> = <a href="#status-line" class="smpl">Status-Line</a> ; <a href="#status-line" title="Status-Line">Section 6.1</a> 1377 1386 *(( <a href="#general.header.fields" class="smpl">general-header</a> ; <a href="#general.header.fields" title="General Header Fields">Section 4.5</a> 1378 1387 / <a href="#abnf.dependencies" class="smpl">response-header</a> ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> … … 1385 1394 CRLF sequence. 1386 1395 </p> 1387 <div id="rfc.figure.u.4 1"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a>1396 <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.78"></span> <a href="#status-line" class="smpl">Status-Line</a> = <a href="#http.version" class="smpl">HTTP-Version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1388 1397 </pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a> <a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 1389 1398 <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes … … 1402 1411 <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 1403 1412 </ul> 1404 <div id="rfc.figure.u.4 2"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a>1413 <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3<a href="#core.rules" class="smpl">DIGIT</a> 1405 1414 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( <a href="#core.rules" class="smpl">WSP</a> / <a href="#core.rules" class="smpl">VCHAR</a> / <a href="#rule.quoted-string" class="smpl">obs-text</a> ) 1406 1415 </pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="connections" href="#connections">Connections</a></h1> … … 1594 1603 </p> 1595 1604 <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p> 1596 <div id="rfc.figure.u.4 3"></div><pre class="inline"><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a>1605 <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span> <a href="#header.connection" class="smpl">Connection</a> = "Connection" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.connection" class="smpl">Connection-v</a> 1597 1606 <a href="#header.connection" class="smpl">Connection-v</a> = 1#<a href="#header.connection" class="smpl">connection-token</a> 1598 1607 <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> … … 1607 1616 of the response. For example, 1608 1617 </p> 1609 <div id="rfc.figure.u.4 4"></div><pre class="text"> Connection: close1618 <div id="rfc.figure.u.46"></div><pre class="text"> Connection: close 1610 1619 </pre><p id="rfc.section.8.1.p.8">in either the request or the response header fields indicates that the connection <em class="bcp14">SHOULD NOT</em> be considered `persistent' (<a href="#persistent.connections" title="Persistent Connections">Section 7.1</a>) after the current request/response is complete. 1611 1620 </p> … … 1623 1632 or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET. 1624 1633 </p> 1625 <div id="rfc.figure.u.4 5"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a>1634 <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span> <a href="#header.content-length" class="smpl">Content-Length</a> = "Content-Length" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1*<a href="#header.content-length" class="smpl">Content-Length-v</a> 1626 1635 <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 1627 1636 </pre><p id="rfc.section.8.2.p.3">An example is</p> 1628 <div id="rfc.figure.u.4 6"></div><pre class="text"> Content-Length: 34951637 <div id="rfc.figure.u.48"></div><pre class="text"> Content-Length: 3495 1629 1638 </pre><p id="rfc.section.8.2.p.5">Applications <em class="bcp14">SHOULD</em> use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in <a href="#message.length" title="Message Length">Section 4.4</a>. 1630 1639 </p> … … 1641 1650 as orig-date in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section 3.2.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 1642 1651 </p> 1643 <div id="rfc.figure.u.4 7"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a>1652 <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span> <a href="#header.date" class="smpl">Date</a> = "Date" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.date" class="smpl">Date-v</a> 1644 1653 <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a> 1645 1654 </pre><p id="rfc.section.8.3.p.3">An example is</p> 1646 <div id="rfc.figure.u. 48"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT1655 <div id="rfc.figure.u.50"></div><pre class="text"> Date: Tue, 15 Nov 1994 08:12:31 GMT 1647 1656 </pre><p id="rfc.section.8.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 1648 1657 </p> … … 1680 1689 a single IP address. 1681 1690 </p> 1682 <div id="rfc.figure.u. 49"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a>1691 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.89"></span><span id="rfc.iref.g.90"></span> <a href="#header.host" class="smpl">Host</a> = "Host" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.host" class="smpl">Host-v</a> 1683 1692 <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section 2.1.1</a> 1684 1693 </pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 1685 1694 URL). For example, a request on the origin server for <http://www.example.org/pub/WWW/> would properly include: 1686 1695 </p> 1687 <div id="rfc.figure.u.5 0"></div><pre class="text"> GET /pub/WWW/ HTTP/1.11696 <div id="rfc.figure.u.52"></div><pre class="text"> GET /pub/WWW/ HTTP/1.1 1688 1697 Host: www.example.org 1689 1698 </pre><p id="rfc.section.8.4.p.5">A client <em class="bcp14">MUST</em> include a Host header field in all HTTP/1.1 request messages. If the requested URI does not include an Internet host name … … 1700 1709 and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>). 1701 1710 </p> 1702 <div id="rfc.figure.u.5 1"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a>1711 <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span><span id="rfc.iref.g.93"></span> <a href="#header.te" class="smpl">TE</a> = "TE" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.te" class="smpl">TE-v</a> 1703 1712 <a href="#header.te" class="smpl">TE-v</a> = #<a href="#header.te" class="smpl">t-codings</a> 1704 1713 <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#abnf.dependencies" class="smpl">accept-params</a> ] ) … … 1707 1716 </p> 1708 1717 <p id="rfc.section.8.5.p.4">Examples of its use are:</p> 1709 <div id="rfc.figure.u.5 2"></div><pre class="text"> TE: deflate1718 <div id="rfc.figure.u.54"></div><pre class="text"> TE: deflate 1710 1719 TE: 1711 1720 TE: trailers, deflate;q=0.5 … … 1744 1753 chunked transfer-coding. 1745 1754 </p> 1746 <div id="rfc.figure.u.5 3"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a>1755 <div id="rfc.figure.u.55"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span> <a href="#header.trailer" class="smpl">Trailer</a> = "Trailer" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.trailer" class="smpl">Trailer-v</a> 1747 1756 <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a> 1748 1757 </pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient … … 1765 1774 transfer-coding is a property of the message, not of the entity. 1766 1775 </p> 1767 <div id="rfc.figure.u.5 4"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a>1776 <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.96"></span><span id="rfc.iref.g.97"></span> <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a> = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 1768 1777 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 1769 1778 <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 1770 1779 </pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section 3.3</a>. An example is: 1771 1780 </p> 1772 <div id="rfc.figure.u.5 5"></div><pre class="text"> Transfer-Encoding: chunked1781 <div id="rfc.figure.u.57"></div><pre class="text"> Transfer-Encoding: chunked 1773 1782 </pre><p id="rfc.section.8.7.p.5">If multiple encodings have been applied to an entity, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification. 1774 1783 </p> … … 1780 1789 to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. 1781 1790 </p> 1782 <div id="rfc.figure.u.5 6"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a>1791 <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.98"></span><span id="rfc.iref.g.99"></span> <a href="#header.upgrade" class="smpl">Upgrade</a> = "Upgrade" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.upgrade" class="smpl">Upgrade-v</a> 1783 1792 <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 1784 1793 </pre><p id="rfc.section.8.8.p.3">For example,</p> 1785 <div id="rfc.figure.u.5 7"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x111794 <div id="rfc.figure.u.59"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 1786 1795 </pre><p id="rfc.section.8.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 1787 1796 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP … … 1812 1821 of all senders along the request/response chain. 1813 1822 </p> 1814 <div id="rfc.figure.u. 58"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a>1823 <div id="rfc.figure.u.60"></div><pre class="inline"><span id="rfc.iref.g.100"></span><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></span><span id="rfc.iref.g.103"></span><span id="rfc.iref.g.104"></span><span id="rfc.iref.g.105"></span><span id="rfc.iref.g.106"></span> <a href="#header.via" class="smpl">Via</a> = "Via" ":" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#header.via" class="smpl">Via-v</a> 1815 1824 <a href="#header.via" class="smpl">Via-v</a> = 1#( <a href="#header.via" class="smpl">received-protocol</a> <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#header.via" class="smpl">received-by</a> 1816 1825 [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) … … 1837 1846 server at www.example.com. The request received by www.example.com would then have the following Via header field: 1838 1847 </p> 1839 <div id="rfc.figure.u. 59"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)1848 <div id="rfc.figure.u.61"></div><pre class="text"> Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 1840 1849 </pre><p id="rfc.section.8.9.p.9">Proxies and gateways used as a portal through a network firewall <em class="bcp14">SHOULD NOT</em>, by default, forward the names and ports of hosts within the firewall region. This information <em class="bcp14">SHOULD</em> only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall <em class="bcp14">SHOULD</em> be replaced by an appropriate pseudonym for that host. 1841 1850 </p> … … 1843 1852 For example, 1844 1853 </p> 1845 <div id="rfc.figure.u.6 0"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy1854 <div id="rfc.figure.u.62"></div><pre class="text"> Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 1846 1855 </pre><p id="rfc.section.8.9.p.12">could be collapsed to</p> 1847 <div id="rfc.figure.u.6 1"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy1856 <div id="rfc.figure.u.63"></div><pre class="text"> Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 1848 1857 </pre><p id="rfc.section.8.9.p.14">Applications <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced 1849 1858 by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. … … 2763 2772 </li> 2764 2773 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/77">http://tools.ietf.org/wg/httpbis/trac/ticket/77</a>>: "Line Folding" 2774 </li> 2775 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/83">http://tools.ietf.org/wg/httpbis/trac/ticket/83</a>>: "OPTIONS * and proxies" 2765 2776 </li> 2766 2777 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/94">http://tools.ietf.org/wg/httpbis/trac/ticket/94</a>>: "Reason-Phrase BNF" -
draft-ietf-httpbis/latest/p1-messaging.xml
r402 r403 1562 1562 </t> 1563 1563 <t> 1564 If a proxy receives a request without any path in the request-target and 1565 the method specified is capable of supporting the asterisk form of 1566 request-target, then the last proxy on the request chain &MUST; forward the 1567 request with "*" as the final request-target. 1568 </t> 1569 <figure><preamble> 1570 For example, the request 1571 </preamble><artwork type="example"> 1572 OPTIONS http://www.example.org:8001 HTTP/1.1 1573 </artwork></figure> 1574 <figure><preamble> 1575 would be forwarded by the proxy as 1576 </preamble><artwork type="example"> 1577 OPTIONS * HTTP/1.1 1578 Host: www.example.org:8001 1579 </artwork> 1580 <postamble> 1581 after connecting to port 8001 of host "www.example.org". 1582 </postamble> 1583 </figure> 1584 <t> 1564 1585 The request-target is transmitted in the format specified in 1565 1586 <xref target="http.uri"/>. If the request-target is encoded using the … … 4688 4709 </t> 4689 4710 <t> 4711 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/83"/>: 4712 "OPTIONS * and proxies" 4713 </t> 4714 <t> 4690 4715 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/94"/>: 4691 4716 "Reason-Phrase BNF"
Note: See TracChangeset
for help on using the changeset viewer.