Changeset 403


Ignore:
Timestamp:
15/11/08 20:16:54 (14 years ago)
Author:
julian.reschke@…
Message:

restore RFC 2068 text describing how to proxy OPTIONS * (addresses #83)

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

Legend:

Unmodified
Added
Removed

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

    r402 r403  
    13341334         URI, it <em class="bcp14">MUST</em> be given as "/" (the server root).
    13351335      </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&nbsp;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&nbsp;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
    13391348         above to replace a null path-absolute with "/".
    13401349      </p>
    1341       <p id="rfc.section.5.1.2.p.14"> </p>
     1350      <p id="rfc.section.5.1.2.p.17"> </p>
    13421351      <dl class="empty">
    13431352         <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
    … …  
    13461355         </dd>
    13471356      </dl>
    1348       <p id="rfc.section.5.1.2.p.15">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
     1357      <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
    13491358         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>).
    13501359      </p>
    1351       <p id="rfc.section.5.1.2.p.16">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.
    13521361      </p>
    13531362      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
    … …  
    13741383      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
    13751384      <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.40"></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&nbsp;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&nbsp;6.1</a>
    13771386                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    13781387                   / <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>
    … …  
    13851394         CRLF sequence.
    13861395      </p>
    1387       <div id="rfc.figure.u.41"></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>
    13881397</pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    13891398      <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
    … …  
    14021411         <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
    14031412      </ul>
    1404       <div id="rfc.figure.u.42"></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>
    14051414  <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> )
    14061415</pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    … …  
    15941603      </p>
    15951604      <p id="rfc.section.8.1.p.2">The Connection header's value has the following grammar:</p>
    1596       <div id="rfc.figure.u.43"></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>
    15971606  <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
    15981607  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
    … …  
    16071616         of the response. For example,
    16081617      </p>
    1609       <div id="rfc.figure.u.44"></div><pre class="text">  Connection: close
     1618      <div id="rfc.figure.u.46"></div><pre class="text">  Connection: close
    16101619</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&nbsp;7.1</a>) after the current request/response is complete.
    16111620      </p>
    … …  
    16231632         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.
    16241633      </p>
    1625       <div id="rfc.figure.u.45"></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>
    16261635  <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
    16271636</pre><p id="rfc.section.8.2.p.3">An example is</p>
    1628       <div id="rfc.figure.u.46"></div><pre class="text">  Content-Length: 3495
     1637      <div id="rfc.figure.u.48"></div><pre class="text">  Content-Length: 3495
    16291638</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&nbsp;4.4</a>.
    16301639      </p>
    … …  
    16411650         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&nbsp;3.2.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16421651      </p>
    1643       <div id="rfc.figure.u.47"></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>
    16441653  <a href="#header.date" class="smpl">Date-v</a> = <a href="#full.date" class="smpl">HTTP-date</a>
    16451654</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 GMT
     1655      <div id="rfc.figure.u.50"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
    16471656</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:
    16481657      </p>
    … …  
    16801689         a single IP address.
    16811690      </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>
    16831692  <a href="#header.host" class="smpl">Host-v</a> = <a href="#uri" class="smpl">uri-host</a> [ ":" <a href="#uri" class="smpl">port</a> ] ; <a href="#http.uri" title="http URI scheme">Section&nbsp;2.1.1</a>
    16841693</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
    16851694         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
    16861695      </p>
    1687       <div id="rfc.figure.u.50"></div><pre class="text">  GET /pub/WWW/ HTTP/1.1
     1696      <div id="rfc.figure.u.52"></div><pre class="text">  GET /pub/WWW/ HTTP/1.1
    16881697  Host: www.example.org
    16891698</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
    … …  
    17001709         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&nbsp;3.3</a>).
    17011710      </p>
    1702       <div id="rfc.figure.u.51"></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>
    17031712  <a href="#header.te" class="smpl">TE-v</a>      = #<a href="#header.te" class="smpl">t-codings</a>
    17041713  <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> ] )
    … …  
    17071716      </p>
    17081717      <p id="rfc.section.8.5.p.4">Examples of its use are:</p>
    1709       <div id="rfc.figure.u.52"></div><pre class="text">  TE: deflate
     1718      <div id="rfc.figure.u.54"></div><pre class="text">  TE: deflate
    17101719  TE:
    17111720  TE: trailers, deflate;q=0.5
    … …  
    17441753         chunked transfer-coding.
    17451754      </p>
    1746       <div id="rfc.figure.u.53"></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>
    17471756  <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#message.headers" class="smpl">field-name</a>
    17481757</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
    … …  
    17651774         transfer-coding is a property of the message, not of the entity.
    17661775      </p>
    1767       <div id="rfc.figure.u.54"></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>
    17681777                        <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a>
    17691778  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
    17701779</pre><p id="rfc.section.8.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.3</a>. An example is:
    17711780      </p>
    1772       <div id="rfc.figure.u.55"></div><pre class="text">  Transfer-Encoding: chunked
     1781      <div id="rfc.figure.u.57"></div><pre class="text">  Transfer-Encoding: chunked
    17731782</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.
    17741783      </p>
    … …  
    17801789         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.
    17811790      </p>
    1782       <div id="rfc.figure.u.56"></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>
    17831792  <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a>
    17841793</pre><p id="rfc.section.8.8.p.3">For example,</p>
    1785       <div id="rfc.figure.u.57"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     1794      <div id="rfc.figure.u.59"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
    17861795</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
    17871796         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
    … …  
    18121821         of all senders along the request/response chain.
    18131822      </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>
    18151824  <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>
    18161825                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
    … …  
    18371846         server at www.example.com. The request received by www.example.com would then have the following Via header field:
    18381847      </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)
    18401849</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.
    18411850      </p>
    … …  
    18431852         For example,
    18441853      </p>
    1845       <div id="rfc.figure.u.60"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
     1854      <div id="rfc.figure.u.62"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
    18461855</pre><p id="rfc.section.8.9.p.12">could be collapsed to</p>
    1847       <div id="rfc.figure.u.61"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
     1856      <div id="rfc.figure.u.63"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
    18481857</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
    18491858         by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
    … …  
    27632772         </li>
    27642773         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/77">http://tools.ietf.org/wg/httpbis/trac/ticket/77</a>&gt;: "Line Folding"
     2774         </li>
     2775         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/83">http://tools.ietf.org/wg/httpbis/trac/ticket/83</a>&gt;: "OPTIONS * and proxies"
    27652776         </li>
    27662777         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/94">http://tools.ietf.org/wg/httpbis/trac/ticket/94</a>&gt;: "Reason-Phrase BNF"

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

    r402 r403  
    15621562</t>
    15631563<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>
    15641585   The request-target is transmitted in the format specified in
    15651586   <xref target="http.uri"/>. If the request-target is encoded using the
    … …  
    46884709    </t>
    46894710    <t>
     4711      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/83"/>:
     4712      "OPTIONS * and proxies"
     4713    </t>
     4714    <t>
    46904715      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/94"/>:
    46914716      "Reason-Phrase BNF"
Note: See TracChangeset for help on using the changeset viewer.