* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 823


Ignore:
Timestamp:
2010-05-26 10:25:13 (5 years ago)
Author:
julian.reschke@gmx.de
Message:

Introduce term "effective request URI" and use it throughout; may require some more fine-tuning (see #196)

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r822 r823  
    573573               </li> 
    574574               <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li> 
     575               <li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li> 
    575576            </ul> 
    576577         </li> 
     
    13841385         what exact resource is being requested. 
    13851386      </p> 
     1387      <div id="rfc.iref.e.1"></div> 
     1388      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2> 
     1389      <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.19"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the resource they are intended for; instead, the value needs to be inferred from the request-target, Host header and 
     1390         other context. The result of this process is the "Effective Request URI". 
     1391      </p> 
     1392      <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the Effective Request URI is the request-target.</p> 
     1393      <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the Effective 
     1394         Request URI is constructed by concatenating 
     1395      </p> 
     1396      <p id="rfc.section.4.3.p.4"> </p> 
     1397      <ul> 
     1398         <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over SSL/TLS-secured 
     1399            TCP connection, 
     1400         </li> 
     1401         <li>the character sequence "://",</li> 
     1402         <li>the authority component, as specified in the Host header (<a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;9.4</a>) and determined by the rules in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section&nbsp;4.2</a>, <span class="comment" id="effrequri-nohost">[<a href="#effrequri-nohost" class="smpl">effrequri-nohost</a>: Do we need to include the handling of missing hosts in HTTP/1.0 messages, as described in <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">Section&nbsp;4.2</a>? --jre]</span> and 
     1403         </li> 
     1404         <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li> 
     1405      </ul> 
     1406      <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p> 
     1407      <div id="rfc.figure.u.40"></div>  
     1408      <p>Example 1: the Effective Request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1 
     1409Host: www.example.org:8080 
     1410</pre>  <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus 
     1411         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". 
     1412      </p>  
     1413      <div id="rfc.figure.u.41"></div>  
     1414      <p>Example 2: the Effective Request URI for the message</p>  <pre class="text">GET * HTTP/1.1 
     1415Host: www.example.org 
     1416</pre>  <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org", 
     1417         thus "https://www.example.org". 
     1418      </p>  
     1419      <p id="rfc.section.4.3.p.8">Effective Request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/". 
     1420      </p> 
    13861421      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1> 
    13871422      <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p> 
    1388       <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.51"></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;5.1</a> 
     1423      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.51"></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;5.1</a> 
    13891424                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.5</a> 
    13901425                   / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.6"><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 5</a> 
     
    13971432         CRLF sequence. 
    13981433      </p> 
    1399       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.52"></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> 
     1434      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.52"></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> 
    14001435</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3> 
    14011436      <p id="rfc.section.5.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 
     
    14141449         <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li> 
    14151450      </ul> 
    1416       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a> 
     1451      <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.53"></span><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span>  <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a>    = 3<a href="#core.rules" class="smpl">DIGIT</a> 
    14171452  <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> ) 
    14181453</pre><h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1> 
     
    14211456      <p id="rfc.section.6.1.p.2">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>: 
    14221457      </p> 
    1423       <div id="rfc.figure.u.43"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123 
     1458      <div id="rfc.figure.u.45"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123 
    14241459</pre><p id="rfc.section.6.1.p.4">The other formats are described here only for compatibility with obsolete implementations.</p> 
    1425       <div id="rfc.figure.u.44"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 
     1460      <div id="rfc.figure.u.46"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format 
    14261461Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format 
    14271462</pre><p id="rfc.section.6.1.p.6">HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;A</a> for further information. 
     
    14311466         time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional whitespace beyond that specifically included as SP in the grammar. 
    14321467      </p> 
    1433       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 
     1468      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.56"></span>  <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a> 
    14341469</pre><div id="preferred.date.format"> 
    14351470         <p id="rfc.section.6.1.p.9">                    Preferred format:</p> 
    14361471      </div> 
    1437       <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 
     1472      <div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.57"></span><span id="rfc.iref.g.58"></span><span id="rfc.iref.g.59"></span><span id="rfc.iref.g.60"></span><span id="rfc.iref.g.61"></span><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span><span id="rfc.iref.g.64"></span><span id="rfc.iref.g.65"></span><span id="rfc.iref.g.66"></span><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#core.rules" class="smpl">SP</a> date1 <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 
    14381473 
    14391474  <a href="#preferred.date.format" class="smpl">day-name</a>     = %x4D.6F.6E ; "Mon", case-sensitive 
     
    14761511         <p id="rfc.section.6.1.p.12">                Obsolete formats:</p> 
    14771512      </div> 
    1478       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.69"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>  
    1479 </pre><div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.70"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 
     1513      <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.69"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a>  
     1514</pre><div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.70"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a> 
    14801515  <a href="#obsolete.date.formats" class="smpl">date2</a>        = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#core.rules" class="smpl">DIGIT</a> 
    14811516                 ; day-month-year (e.g., 02-Jun-82) 
     
    14881523         / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive 
    14891524         / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive 
    1490 </pre><div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 
     1525</pre><div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.71"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#core.rules" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#core.rules" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a> 
    14911526  <a href="#obsolete.date.formats" class="smpl">date3</a>        = <a href="#preferred.date.format" class="smpl">month</a> <a href="#core.rules" class="smpl">SP</a> ( 2<a href="#core.rules" class="smpl">DIGIT</a> / ( <a href="#core.rules" class="smpl">SP</a> 1<a href="#core.rules" class="smpl">DIGIT</a> )) 
    14921527                 ; month day (e.g., Jun  2) 
     
    15061541         is a property of the message, not of the original entity. 
    15071542      </p> 
    1508       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a> 
     1543      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.72"></span><span id="rfc.iref.g.73"></span>  <a href="#transfer.codings" class="smpl">transfer-coding</a>         = "chunked" ; <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;6.2.1</a> 
    15091544                          / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;6.2.2.1</a> 
    15101545                          / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;6.2.2.2</a> 
     
    15151550         <p id="rfc.section.6.2.p.3">      Parameters are in the form of attribute/value pairs.</p> 
    15161551      </div> 
    1517       <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 
     1552      <div id="rfc.figure.u.53"></div><pre class="inline"><span id="rfc.iref.g.74"></span><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span><span id="rfc.iref.g.77"></span><span id="rfc.iref.g.78"></span>  <a href="#rule.parameter" class="smpl">transfer-parameter</a>      = <a href="#rule.parameter" class="smpl">attribute</a> <a href="#rule.whitespace" class="smpl">BWS</a> "=" <a href="#rule.whitespace" class="smpl">BWS</a> <a href="#rule.parameter" class="smpl">value</a> 
    15181553  <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a> 
    15191554  <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a> 
     
    15371572         necessary for the recipient to verify that it has received the full message. 
    15381573      </p> 
    1539       <div id="rfc.figure.u.52"></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><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a> 
     1574      <div id="rfc.figure.u.54"></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><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a> 
    15401575                   <a href="#chunked.encoding" class="smpl">last-chunk</a> 
    15411576                   <a href="#chunked.encoding" class="smpl">trailer-part</a> 
     
    15801615      </p> 
    15811616      <p id="rfc.section.6.2.1.p.7">A process for decoding the "chunked" transfer-coding can be represented in pseudo-code as:</p> 
    1582       <div id="rfc.figure.u.53"></div><pre class="text">  length := 0 
     1617      <div id="rfc.figure.u.55"></div><pre class="text">  length := 0 
    15831618  read chunk-size, chunk-ext (if any) and CRLF 
    15841619  while (chunk-size &gt; 0) { 
     
    16491684         By convention, the products are listed in order of their significance for identifying the application. 
    16501685      </p> 
    1651       <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 
     1686      <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.91"></span><span id="rfc.iref.g.92"></span>  <a href="#product.tokens" class="smpl">product</a>         = <a href="#rule.token.separators" class="smpl">token</a> ["/" <a href="#product.tokens" class="smpl">product-version</a>] 
    16521687  <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a> 
    16531688</pre><p id="rfc.section.6.3.p.3">Examples:</p> 
    1654       <div id="rfc.figure.u.55"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3 
     1689      <div id="rfc.figure.u.57"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3 
    16551690  Server: Apache/0.8.4 
    16561691</pre><p id="rfc.section.6.3.p.5">Product tokens <em class="bcp14">SHOULD</em> be short and to the point. They <em class="bcp14">MUST NOT</em> be used for advertising or other non-essential information. Although any token character <em class="bcp14">MAY</em> appear in a product-version, this token <em class="bcp14">SHOULD</em> only be used for a version identifier (i.e., successive versions of the same product <em class="bcp14">SHOULD</em> only differ in the product-version portion of the product value). 
     
    16611696         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. 
    16621697      </p> 
    1663       <div id="rfc.figure.u.56"></div><pre class="inline"><span id="rfc.iref.g.93"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 
     1698      <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.93"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] ) 
    16641699                 / ( "1" [ "." 0*3("0") ] ) 
    16651700</pre><div class="note" id="rfc.section.6.4.p.3">  
     
    19451980      </p> 
    19461981      <p id="rfc.section.9.1.p.2">The Connection header's value has the following grammar:</p> 
    1947       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></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> 
     1982      <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.94"></span><span id="rfc.iref.g.95"></span><span id="rfc.iref.g.96"></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> 
    19481983  <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a> 
    19491984  <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a> 
     
    19581993         of the response. For example, 
    19591994      </p> 
    1960       <div id="rfc.figure.u.58"></div><pre class="text">  Connection: close 
     1995      <div id="rfc.figure.u.60"></div><pre class="text">  Connection: close 
    19611996</pre><p id="rfc.section.9.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. 
    19621997      </p> 
     
    19742009         to the HEAD method, it indicates the size of the entity-body that would have been sent had the request been a GET. 
    19752010      </p> 
    1976       <div id="rfc.figure.u.59"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></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> 
     2011      <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.97"></span><span id="rfc.iref.g.98"></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> 
    19772012  <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a> 
    19782013</pre><p id="rfc.section.9.2.p.3">An example is</p> 
    1979       <div id="rfc.figure.u.60"></div><pre class="text">  Content-Length: 3495 
     2014      <div id="rfc.figure.u.62"></div><pre class="text">  Content-Length: 3495 
    19802015</pre><p id="rfc.section.9.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;3.4</a>. 
    19812016      </p> 
     
    19922027         as the Origination Date Field (orig-date) defined 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="#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section&nbsp;6.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 
    19932028      </p> 
    1994       <div id="rfc.figure.u.61"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></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> 
     2029      <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.99"></span><span id="rfc.iref.g.100"></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> 
    19952030  <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a> 
    19962031</pre><p id="rfc.section.9.3.p.3">An example is</p> 
    1997       <div id="rfc.figure.u.62"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT 
     2032      <div id="rfc.figure.u.64"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT 
    19982033</pre><p id="rfc.section.9.3.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases:  
    19992034      </p> 
     
    20332068         resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>). 
    20342069      </p> 
    2035       <div id="rfc.figure.u.63"></div><pre class="inline"><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></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> 
     2070      <div id="rfc.figure.u.65"></div><pre class="inline"><span id="rfc.iref.g.101"></span><span id="rfc.iref.g.102"></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> 
    20362071  <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.6.1</a> 
    20372072</pre><p id="rfc.section.9.4.p.4">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP 
    20382073         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include: 
    20392074      </p> 
    2040       <div id="rfc.figure.u.64"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 
     2075      <div id="rfc.figure.u.66"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1 
    20412076Host: www.example.org 
    20422077</pre><p id="rfc.section.9.4.p.6">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 
     
    20552090         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>). 
    20562091      </p> 
    2057       <div id="rfc.figure.u.65"></div><pre class="inline"><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><span id="rfc.iref.g.107"></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> 
     2092      <div id="rfc.figure.u.67"></div><pre class="inline"><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><span id="rfc.iref.g.107"></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> 
    20582093  <a href="#header.te" class="smpl">TE-v</a>      = #<a href="#header.te" class="smpl">t-codings</a> 
    20592094  <a href="#header.te" class="smpl">t-codings</a> = "trailers" / ( <a href="#transfer.codings" class="smpl">transfer-extension</a> [ <a href="#header.te" class="smpl">te-params</a> ] ) 
     
    20642099      </p> 
    20652100      <p id="rfc.section.9.5.p.5">Examples of its use are:</p> 
    2066       <div id="rfc.figure.u.66"></div><pre class="text">  TE: deflate 
     2101      <div id="rfc.figure.u.68"></div><pre class="text">  TE: deflate 
    20672102  TE: 
    20682103  TE: trailers, deflate;q=0.5 
     
    21012136         with chunked transfer-coding. 
    21022137      </p> 
    2103       <div id="rfc.figure.u.67"></div><pre class="inline"><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></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> 
     2138      <div id="rfc.figure.u.69"></div><pre class="inline"><span id="rfc.iref.g.108"></span><span id="rfc.iref.g.109"></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> 
    21042139  <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a> 
    21052140</pre><p id="rfc.section.9.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 
     
    21222157         are not. 
    21232158      </p> 
    2124       <div id="rfc.figure.u.68"></div><pre class="inline"><span id="rfc.iref.g.110"></span><span id="rfc.iref.g.111"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 
     2159      <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.110"></span><span id="rfc.iref.g.111"></span>  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding</a>   = "Transfer-Encoding" ":" <a href="#rule.whitespace" class="smpl">OWS</a> 
    21252160                        <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> 
    21262161  <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a> 
    21272162</pre><p id="rfc.section.9.7.p.3">Transfer-codings are defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>. An example is: 
    21282163      </p> 
    2129       <div id="rfc.figure.u.69"></div><pre class="text">  Transfer-Encoding: chunked 
     2164      <div id="rfc.figure.u.71"></div><pre class="text">  Transfer-Encoding: chunked 
    21302165</pre><p id="rfc.section.9.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. 
    21312166      </p> 
     
    21382173         to. 
    21392174      </p> 
    2140       <div id="rfc.figure.u.70"></div><pre class="inline"><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></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> 
     2175      <div id="rfc.figure.u.72"></div><pre class="inline"><span id="rfc.iref.g.112"></span><span id="rfc.iref.g.113"></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> 
    21412176  <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a> 
    21422177</pre><p id="rfc.section.9.8.p.3">For example,</p> 
    2143       <div id="rfc.figure.u.71"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 
     2178      <div id="rfc.figure.u.73"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 
    21442179</pre><p id="rfc.section.9.8.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible 
    21452180         protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 
     
    21942229         of all senders along the request/response chain. 
    21952230      </p> 
    2196       <div id="rfc.figure.u.72"></div><pre class="inline"><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span><span id="rfc.iref.g.118"></span><span id="rfc.iref.g.119"></span><span id="rfc.iref.g.120"></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> 
     2231      <div id="rfc.figure.u.74"></div><pre class="inline"><span id="rfc.iref.g.114"></span><span id="rfc.iref.g.115"></span><span id="rfc.iref.g.116"></span><span id="rfc.iref.g.117"></span><span id="rfc.iref.g.118"></span><span id="rfc.iref.g.119"></span><span id="rfc.iref.g.120"></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> 
    21972232  <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> 
    21982233                          [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] ) 
     
    22192254         server at www.example.com. The request received by www.example.com would then have the following Via header field: 
    22202255      </p> 
    2221       <div id="rfc.figure.u.73"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 
     2256      <div id="rfc.figure.u.75"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1) 
    22222257</pre><p id="rfc.section.9.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. 
    22232258      </p> 
     
    22252260         For example, 
    22262261      </p> 
    2227       <div id="rfc.figure.u.74"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 
     2262      <div id="rfc.figure.u.76"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 
    22282263</pre><p id="rfc.section.9.9.p.12">could be collapsed to</p> 
    2229       <div id="rfc.figure.u.75"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 
     2264      <div id="rfc.figure.u.77"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 
    22302265</pre><p id="rfc.section.9.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 
    22312266         by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values. 
     
    22722307                  <td class="left">http</td> 
    22732308                  <td class="left">standard</td> 
    2274                   <td class="left"> <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;9.4</a>  
     2309                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;9.4</a>  
    22752310                  </td> 
    22762311               </tr> 
     
    28652900      <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p> 
    28662901      <h3 id="rfc.section.B.1.1"><a href="#rfc.section.B.1.1">B.1.1</a>&nbsp;<a id="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses</a></h3> 
    2867       <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;9.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification. 
     2902      <p id="rfc.section.B.1.1.p.1">The requirements that clients and servers support the Host request-header, report an error if the Host request-header (<a href="#header.host" id="rfc.xref.header.host.3" title="Host">Section&nbsp;9.4</a>) is missing from an HTTP/1.1 request, and accept absolute URIs (<a href="#request-target" title="request-target">Section&nbsp;4.1.2</a>) are among the most important changes defined by this specification. 
    28682903      </p> 
    28692904      <p id="rfc.section.B.1.1.p.2">Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism 
     
    29472982      </p> 
    29482983      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 
    2949       <div id="rfc.figure.u.76"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 
     2984      <div id="rfc.figure.u.78"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS 
    29502985 
    29512986<a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt; 
     
    31383173 
    31393174<a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT 
    3140 </pre> <div id="rfc.figure.u.77"></div> 
     3175</pre> <div id="rfc.figure.u.79"></div> 
    31413176      <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used 
    31423177; Content-Length defined but not used 
     
    33963431         </li> 
    33973432      </ul> 
     3433      <p id="rfc.section.D.11.p.2">Partly resolved issues: </p> 
     3434      <ul> 
     3435         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI" 
     3436         </li> 
     3437      </ul> 
    33983438      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 
    3399       <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a>  
     3439      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.K">K</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a>  
    34003440      </p> 
    34013441      <div class="print2col"> 
     
    34323472                  <li class="indline1">deflate (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li> 
    34333473                  <li class="indline1">downstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li> 
     3474               </ul> 
     3475            </li> 
     3476            <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind"> 
     3477                  <li class="indline1">Effective Request URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li> 
    34343478               </ul> 
    34353479            </li> 
     
    35703614                        <li class="indline1">Content-Length&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.4</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a>, <a class="iref" href="#rfc.xref.header.content-length.3">B.3</a></li> 
    35713615                        <li class="indline1">Date&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.5</a>, <a class="iref" href="#rfc.iref.h.8"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li> 
    3572                         <li class="indline1">Host&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.10"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">10.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li> 
     3616                        <li class="indline1">Host&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.host.1">4.3</a>, <a class="iref" href="#rfc.iref.h.10"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.2">10.1</a>, <a class="iref" href="#rfc.xref.header.host.3">B.1.1</a></li> 
    35733617                        <li class="indline1">TE&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.h.11"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a>, <a class="iref" href="#rfc.xref.header.te.5">B.3</a></li> 
    35743618                        <li class="indline1">Trailer&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.5</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.h.12"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li> 
     
    35783622                     </ul> 
    35793623                  </li> 
    3580                   <li class="indline1">Host header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.9"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.1">10.1</a>, <a class="iref" href="#rfc.xref.header.host.2">B.1.1</a></li> 
     3624                  <li class="indline1">Host header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.host.1">4.3</a>, <a class="iref" href="#rfc.iref.h.9"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.host.2">10.1</a>, <a class="iref" href="#rfc.xref.header.host.3">B.1.1</a></li> 
    35813625                  <li class="indline1">http URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.1"><b>2.6.1</b></a></li> 
    35823626                  <li class="indline1">https URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.2">2.6.2</a></li> 
     
    36793723                  <li class="indline1"><em>RFC2965</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2965.1">3.2</a>, <a class="iref" href="#RFC2965"><b>13.2</b></a></li> 
    36803724                  <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">10.1</a>, <a class="iref" href="#RFC3864"><b>13.2</b></a></li> 
    3681                   <li class="indline1"><em>RFC3986</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.13">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.14">2.6.1</a>, <a class="iref" href="#rfc.xref.RFC3986.15">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.16">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.17">4.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.18">4.1.2</a>, <a class="iref" href="#RFC3986"><b>13.1</b></a><ul class="ind"> 
     3725                  <li class="indline1"><em>RFC3986</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.1">1</a>, <a class="iref" href="#rfc.xref.RFC3986.2">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.3">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.4">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.5">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.6">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.7">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.8">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.9">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.10">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.11">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.12">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.13">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.14">2.6.1</a>, <a class="iref" href="#rfc.xref.RFC3986.15">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.16">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.17">4.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.18">4.1.2</a>, <a class="iref" href="#rfc.xref.RFC3986.19">4.3</a>, <a class="iref" href="#RFC3986"><b>13.1</b></a><ul class="ind"> 
    36823726                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.16">2.6.3</a>, <a class="iref" href="#rfc.xref.RFC3986.17">4.1.2</a></li> 
    36833727                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.8">2.6</a></li> 
     
    36893733                        <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.5">2.6</a></li> 
    36903734                        <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.7">2.6</a></li> 
    3691                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.6">2.6</a></li> 
     3735                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.6">2.6</a>, <a class="iref" href="#rfc.xref.RFC3986.19">4.3</a></li> 
    36923736                        <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.15">2.6.3</a></li> 
    36933737                     </ul> 
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r822 r823  
    15951595   exact resource is being requested. 
    15961596</t> 
     1597</section> 
     1598 
     1599<section title="Effective Request URI" anchor="effective.request.uri"> 
     1600  <iref primary="true" item="Effective Request URI"/> 
     1601<t> 
     1602   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>) 
     1603   for the resource they are intended for; instead, the value needs to be inferred from the 
     1604   request-target, Host header and other context. The result of this process is 
     1605   the "Effective Request URI". 
     1606</t> 
     1607<t> 
     1608   If the request-target is an absolute-URI, then the Effective Request URI is 
     1609   the request-target. 
     1610</t> 
     1611<t> 
     1612   If the request-target uses the path-absolute (plus optional query) syntax 
     1613   or if it is just the asterisk "*", then the Effective Request URI is 
     1614   constructed by concatenating 
     1615</t> 
     1616<t> 
     1617  <list style="symbols"> 
     1618    <t> 
     1619      the scheme name: "http" if the request was received over an insecure 
     1620      TCP connection, or "https" when received over SSL/TLS-secured TCP 
     1621      connection, 
     1622    </t> 
     1623    <t> 
     1624      the character sequence "://", 
     1625    </t> 
     1626    <t> 
     1627      the authority component, as specified in the Host header 
     1628      (<xref target="header.host"/>) and determined by the rules in 
     1629      <xref target="the.resource.identified.by.a.request"/>, 
     1630      <cref anchor="effrequri-nohost" source="jre">Do we need to include the handling of missing hosts in HTTP/1.0 messages, as 
     1631      described in <xref target="the.resource.identified.by.a.request"/>?</cref> 
     1632      and 
     1633    </t> 
     1634    <t> 
     1635      the request-target obtained from the Request-Line, unless the 
     1636      request-target is just the asterisk "*". 
     1637    </t> 
     1638  </list> 
     1639</t> 
     1640<t> 
     1641   Otherwise, when request-target uses the authority form, the Effective 
     1642   Request URI is undefined. 
     1643</t> 
     1644<figure> 
     1645<preamble> 
     1646   Example 1: the Effective Request URI for the message 
     1647</preamble>  
     1648<artwork type="example" x:indent-with="  "> 
     1649GET /pub/WWW/TheProject.html HTTP/1.1 
     1650Host: www.example.org:8080 
     1651</artwork> 
     1652<postamble> 
     1653  (received over an insecure TCP connection) is "http", plus "://", plus the 
     1654  authority component "www.example.org:8080", plus the request-target 
     1655  "/pub/WWW/TheProject.html", thus 
     1656  "http://www.example.org:8080/pub/WWW/TheProject.html". 
     1657</postamble> 
     1658</figure> 
     1659<figure> 
     1660<preamble> 
     1661   Example 2: the Effective Request URI for the message 
     1662</preamble>  
     1663<artwork type="example" x:indent-with="  "> 
     1664GET * HTTP/1.1 
     1665Host: www.example.org 
     1666</artwork> 
     1667<postamble> 
     1668  (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the 
     1669  authority component "www.example.org", thus "https://www.example.org". 
     1670</postamble> 
     1671</figure> 
     1672<t> 
     1673   Effective Request URIs are compared using the rules described in  
     1674   <xref target="uri.comparison"/>, except that empty path components &MUST-NOT; 
     1675   be treated as equivalent to an absolute path of "/". 
     1676</t>   
    15971677</section> 
    15981678 
     
    55565636  </list> 
    55575637</t> 
     5638<t> 
     5639  Partly resolved issues: 
     5640  <list style="symbols">  
     5641    <t> 
     5642      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 
     5643      "Term for the requested resource's URI" 
     5644    </t> 
     5645  </list> 
     5646</t> 
    55585647</section> 
    55595648 
  • draft-ietf-httpbis/latest/p2-semantics.html

    r818 r823  
    403403      <meta name="dct.creator" content="Reschke, J. F."> 
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-05-07"> 
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> 
     
    434434            </tr> 
    435435            <tr> 
    436                <td class="left">Expires: November 8, 2010</td> 
     436               <td class="left">Expires: November 27, 2010</td> 
    437437               <td class="right">HP</td> 
    438438            </tr> 
     
    487487            <tr> 
    488488               <td class="left"></td> 
    489                <td class="right">May 7, 2010</td> 
     489               <td class="right">May 26, 2010</td> 
    490490            </tr> 
    491491         </tbody> 
     
    514514         in progress”. 
    515515      </p> 
    516       <p>This Internet-Draft will expire in November 8, 2010.</p> 
     516      <p>This Internet-Draft will expire in November 27, 2010.</p> 
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    753753             &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>&gt; 
    754754</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1> 
    755       <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p> 
     755      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive. 
     756      </p> 
    756757      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a> 
    757758                 / %x47.45.54               ; "GET", <a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;7.3</a> 
     
    796797                 / <a href="#header.expect" class="smpl">Expect</a>                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.2</a> 
    797798                 / <a href="#header.from" class="smpl">From</a>                     ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;9.3</a> 
    798                  / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> 
     799                 / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a> 
    799800                 / <a href="#abnf.dependencies" class="smpl">If-Match</a>                 ; <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a> 
    800801                 / <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a>        ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a> 
     
    806807                 / <a href="#abnf.dependencies" class="smpl">Range</a>                    ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a> 
    807808                 / <a href="#header.referer" class="smpl">Referer</a>                  ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;9.6</a> 
    808                  / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> 
     809                 / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a> 
    809810                 / <a href="#header.user-agent" class="smpl">User-Agent</a>               ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;9.9</a> 
    810811</pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new 
     
    880881      <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the 
    881882         Status-Line. These header fields give information about the server and about further access to the resource identified by 
    882          the request-target. 
     883         the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
    883884      </p> 
    884885      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> 
     
    901902         fields are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 
    902903      </p> 
    903       <p id="rfc.section.6.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 
     904      <p id="rfc.section.6.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure 
    904905         safe and proper transfer of the message. 
    905906      </p> 
     
    907908      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p> 
    908909      <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p> 
    909       <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the request-URI. However, this is not 
    910          always the case. To determine the URI of the resource a response is associated with, the following rules are used (with the 
    911          first applicable one being selected): 
     910      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following 
     911         rules are used (with the first applicable one being selected): 
    912912      </p> 
    913913      <ol> 
    914914         <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource 
    915             at the request-URI. 
     915            at the Effective Request URI. 
    916916         </li> 
    917917         <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation 
    918             of the resource at the request-URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 
    919          </li> 
    920          <li>If the response has a Content-Location header, and that URI is the same as the request-URI <span class="comment" id="TODO-missref-requri">[<a href="#TODO-missref-requri" class="smpl">TODO-missref-requri</a>: (see [ref])]</span>, the response is a representation of the resource at the request-URI. 
    921          </li> 
    922          <li>If the response has a Content-Location header, and that URI is not the same as the request-URI, the response asserts that 
    923             it is a representation of the resource at the Content-Location URI (but it may not be). 
     918            of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 
     919         </li> 
     920         <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation 
     921            of the resource at the Effective Request URI. 
     922         </li> 
     923         <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts 
     924            that it is a representation of the resource at the Content-Location URI (but it may not be). 
    924925         </li> 
    925926         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li> 
    926927      </ol> 
    927       <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: Note that "request-URI" is used here; however, we need to come up with a term to denote "the URI that can be inferred from 
    928             examining the request-target and the Host header." (see &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;). Also, the comparison function is going to have to be defined somewhere, because we already need to compare URIs for things 
    929             like cache invalidation.]</span>  
     928      <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like 
     929            cache invalidation.]</span>  
    930930      </p> 
    931931      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h1> 
     
    958958      <div id="rfc.iref.m.1"></div> 
    959959      <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response 
    960          chain identified by the request-target. This method allows the client to determine the options and/or requirements associated 
    961          with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 
     960         chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements 
     961         associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. 
    962962      </p> 
    963963      <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p> 
     
    986986      <div id="rfc.iref.m.2"></div> 
    987987      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of an entity) currently corresponds to the resource identified 
    988          by the request-target. 
    989       </p> 
    990       <p id="rfc.section.7.3.p.2">If the request-target identifies a data-producing process, it is the produced data which shall be returned as the entity in 
    991          the response and not the source text of the process, unless that text happens to be the output of the process. 
     988         by the Effective Request URI. 
     989      </p> 
     990      <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the entity 
     991         in the response and not the source text of the process, unless that text happens to be the output of the process. 
    992992      </p> 
    993993      <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, 
     
    10201020      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2> 
    10211021      <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed 
    1022          by the resource identified by the request-target in the Request-Line. POST is designed to allow a uniform method to cover 
    1023          the following functions:  
     1022         by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the following 
     1023         functions:  
    10241024      </p> 
    10251025      <ul> 
     
    10291029         <li>Extending a database through an append operation.</li> 
    10301030      </ul> 
    1031       <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the request-target.</p> 
     1031      <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Effective Request 
     1032         URI. 
     1033      </p> 
    10321034      <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 
    10331035         200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity 
     
    10431045      <div id="rfc.iref.m.5"></div> 
    10441046      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2> 
    1045       <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the supplied request-target. If the request-target refers to 
    1046          an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the request-target does not point to an existing 
    1047          resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create 
    1048          the resource with that URI. If a new resource is created at the request-target, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 
    1049          Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the request-target, 
    1050          an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 
    1051       </p> 
    1052       <p id="rfc.section.7.6.p.2">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 
    1053       </p> 
    1054       <p id="rfc.section.7.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the request-target. 
    1055          The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 
     1047      <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the Effective Request URI. If the Effective Request URI refers 
     1048         to an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does 
     1049         not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, 
     1050         the origin server can create the resource with that URI. 
     1051      </p> 
     1052      <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No 
     1053         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. 
     1054      </p> 
     1055      <p id="rfc.section.7.6.p.3">If the resource could not be created or modified with the Effective Request URI, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases. 
     1056      </p> 
     1057      <p id="rfc.section.7.6.p.4">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those 
     1058         entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 
     1059      </p> 
     1060      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request 
     1061         URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting 
    10561062         process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request 
    10571063         identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, 
    10581064         it <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request. 
    10591065      </p> 
    1060       <p id="rfc.section.7.6.p.4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which 
     1066      <p id="rfc.section.7.6.p.6">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which 
    10611067         is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in 
    10621068         several other URIs being defined by the origin server. 
    10631069      </p> 
    1064       <p id="rfc.section.7.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> 
    1065       <p id="rfc.section.7.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. 
     1070      <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p> 
     1071      <p id="rfc.section.7.6.p.8">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. 
    10661072      </p> 
    10671073      <div id="rfc.iref.d.1"></div> 
    10681074      <div id="rfc.iref.m.6"></div> 
    10691075      <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2> 
    1070       <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the request-target. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 
     1076      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective Request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation 
    10711077         has been carried out, even if the status code returned from the origin server indicates that the action has been completed 
    10721078         successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible 
     
    10761082         or 204 (No Content) if the action has been enacted but the response does not include an entity. 
    10771083      </p> 
    1078       <p id="rfc.section.7.7.p.3">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 
     1084      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those 
     1085         entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable. 
    10791086      </p> 
    10801087      <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h2> 
     
    10861093      </p> 
    10871094      <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 
    1088          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.20"><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 
     1095         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.23"><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 
    10891096         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 
    10901097         infinite loop. 
    10911098      </p> 
    1092       <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached. 
     1099      <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached. 
    10931100      </p> 
    10941101      <div id="rfc.iref.c.1"></div> 
     
    11171124      <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 
    11181125         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 
    1119          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.22"><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. 
     1126         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.25"><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. 
    11201127      </p> 
    11211128      <div id="rfc.iref.26"></div> 
     
    12281235      <div id="rfc.iref.s.12"></div> 
    12291236      <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3> 
    1230       <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target 
    1231          to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise. 
     1237      <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Effective 
     1238         Request URI to one or more of the new references returned by the server, where possible. This response is cacheable unless 
     1239         indicated otherwise. 
    12321240      </p> 
    12331241      <p id="rfc.section.8.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 
     
    12451253      <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3> 
    12461254      <p id="rfc.section.8.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the 
    1247          client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or 
    1248          Expires header field. 
     1255         client <em class="bcp14">SHOULD</em> continue to use the Effectice Request URI for future requests. This response is only cacheable if indicated by a Cache-Control 
     1256         or Expires header field. 
    12491257      </p> 
    12501258      <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 
     
    12981306      <div id="rfc.iref.s.18"></div> 
    12991307      <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3> 
    1300       <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or 
    1301          Expires header field. 
     1308      <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests. This response is only cacheable if indicated by a Cache-Control 
     1309         or Expires header field. 
    13021310      </p> 
    13031311      <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand 
     
    13411349      <div id="rfc.iref.s.23"></div> 
    13421350      <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3> 
    1343       <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the request-target. No indication is given of whether the condition is temporary 
     1351      <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary 
    13441352         or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable 
    13451353         and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request 
     
    13491357      <div id="rfc.iref.s.24"></div> 
    13501358      <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3> 
    1351       <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the request-target. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 
     1359      <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource. 
    13521360      </p> 
    13531361      <div id="rfc.iref.48"></div> 
     
    13961404      <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3> 
    13971405      <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected 
    1398          to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the request-target after user approval. If the server does not know, or has no facility to determine, 
     1406         to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine, 
    13991407         whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. This response is cacheable unless indicated otherwise. 
    14001408      </p> 
     
    14281436      <div id="rfc.iref.s.33"></div> 
    14291437      <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3> 
    1430       <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the request-target is longer than the server is willing to interpret. 
     1438      <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret. 
    14311439         This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long 
    14321440         query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that 
    14331441         points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present 
    1434          in some servers using fixed-length buffers for reading or manipulating the request-target. 
     1442         in some servers using fixed-length buffers for reading or manipulating the Effective Request URI. 
    14351443      </p> 
    14361444      <div id="rfc.iref.57"></div> 
     
    14981506      <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 
    14991507         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 
    1500          in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.23"><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. 
     1508         in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.26"><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. 
    15011509      </p> 
    15021510      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 
     
    15081516      <div id="rfc.iref.h.2"></div> 
    15091517      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2> 
    1510       <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target. 
    1511          The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. 
     1518      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective 
     1519         Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. 
    15121520      </p> 
    15131521      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a> 
     
    15431551      </p> 
    15441552      <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> 
    1545       <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.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status. 
     1553      <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.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status. 
    15461554      </p> 
    15471555      <div id="rfc.iref.f.1"></div> 
     
    16151623      <div id="rfc.iref.h.7"></div> 
    16161624      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2> 
    1617       <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the request-target 
    1618          was obtained (the "referrer", although the header field is misspelled.). 
     1625      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request 
     1626         URI was obtained (the "referrer", although the header field is misspelled.). 
    16191627      </p> 
    16201628      <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc. 
     
    16231631         contain a Referer header field. 
    16241632      </p> 
    1625       <p id="rfc.section.9.6.p.3">If the request-target was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the 
    1626          Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 
     1633      <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard), 
     1634         the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with 
    16271635         non-HTTP URIs (e.g., FTP). 
    16281636      </p> 
     
    16311639</pre><p id="rfc.section.9.6.p.5">Example:</p> 
    16321640      <div id="rfc.figure.u.22"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html 
    1633 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the request-target. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations. 
     1641</pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Effective Request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations. 
    16341642      </p> 
    16351643      <div id="rfc.iref.r.2"></div> 
     
    16551663      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2> 
    16561664      <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.</p> 
    1657       <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 
     1665      <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for 
    16581666         identifying the application. 
    16591667      </p> 
     
    16631671</pre><p id="rfc.section.9.8.p.4">Example:</p> 
    16641672      <div id="rfc.figure.u.27"></div><pre class="text">  Server: CERN/3.0 libwww/2.17 
    1665 </pre><p id="rfc.section.9.8.p.6">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 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
     1673</pre><p id="rfc.section.9.8.p.6">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 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
    16661674      </p> 
    16671675      <div class="note" id="rfc.section.9.8.p.7">  
     
    16781686         to avoid particular user agent limitations. 
    16791687      </p> 
    1680       <p id="rfc.section.9.9.p.2">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 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens 
     1688      <p id="rfc.section.9.9.p.2">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 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens 
    16811689         are listed in order of their significance for identifying the application. 
    16821690      </p> 
     
    21142122      </p> 
    21152123      <p id="rfc.section.11.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded 
    2116          in the Request-target. Many existing servers, proxies, and user agents log or display the Request-target in places where it 
     2124         in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it 
    21172125         might be visible to third parties. Such services can use POST-based form submission instead. 
    21182126      </p> 
     
    22822290      </p> 
    22832291      <p id="rfc.section.A.2.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 
    2284          in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>) 
     2292         in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>) 
    22852293      </p> 
    22862294      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 
     
    25652573      <ul> 
    25662574         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>&gt;: "Location header payload handling" 
     2575         </li> 
     2576         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI" 
    25672577         </li> 
    25682578      </ul> 
     
    27352745            </li> 
    27362746            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 
    2737                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a><ul class="ind"> 
     2747                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.21">6</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a>, <a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.26">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a><ul class="ind"> 
    27382748                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2</a></li> 
    27392749                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li> 
    2740                         <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.23">8.5.6</a></li> 
     2750                        <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">8.5.6</a></li> 
    27412751                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li> 
    2742                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a></li> 
    2743                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">6</a></li> 
     2752                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a></li> 
     2753                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">6</a></li> 
     2754                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a></li> 
    27442755                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li> 
    2745                         <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a></li> 
    2746                         <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li> 
    2747                         <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">3</a></li> 
    2748                         <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a></li> 
    2749                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a></li> 
    2750                         <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">7.8</a></li> 
     2756                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a></li> 
     2757                        <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a></li> 
     2758                        <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3</a></li> 
     2759                        <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a></li> 
     2760                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a></li> 
     2761                        <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.24">7.8</a></li> 
    27512762                     </ul> 
    27522763                  </li> 
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r818 r823  
    2727  <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    2828  <!ENTITY uri                        "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     29  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    2930  <!ENTITY full-date                  "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3031  <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     
    423424  <x:anchor-alias value="extension-method"/> 
    424425<t> 
    425    The Method  token indicates the method to be performed on the 
    426    resource identified by the request-target. The method is case-sensitive. 
     426   The Method token indicates the method to be performed on the resource 
     427   identified by the Effective Request URI (&effective-request-uri;). The 
     428   method is case-sensitive. 
    427429</t> 
    428430<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/> 
     
    621623   information about the response which cannot be placed in the Status-Line. 
    622624   These header fields give information about the server and about 
    623    further access to the resource identified by the request-target. 
     625   further access to the resource identified by the Effective Request URI 
     626   (&effective-request-uri;). 
    624627</t> 
    625628<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/> 
     
    671674<t> 
    672675   In the common case, an HTTP response is a representation of the resource 
    673    located at the request-URI. However, this is not always the case. To 
    674    determine the URI of the resource a response is associated with, the 
    675    following rules are used (with the first applicable one being selected): 
     676   located at the Effective Request URI (see &effective-request-uri;). However, 
     677   this is not always the case. To determine the URI of the resource a 
     678   response is associated with, the following rules are used (with the first 
     679   applicable one being selected): 
    676680</t> 
    677681<t><list style="numbers"> 
    678682   <t>If the response status code is 200 or 203 and the request method was GET, 
    679    the response is a representation of the resource at the request-URI.</t> 
     683   the response is a representation of the resource at the Effective Request URI.</t> 
    680684   <t>If the response status is 204, 206, or 304 and the request method was GET 
    681685   or HEAD, the response is a partial representation of the resource at the 
    682    request-URI (see &caching-combining-headers;).</t> 
     686   Effective Request URI (see &caching-combining-headers;).</t> 
    683687   <t>If the response has a Content-Location header, and that URI is the same 
    684    as the request-URI <cref anchor="TODO-missref-requri">(see [ref])</cref>, the response is a representation of the 
    685    resource at the request-URI.</t> 
     688   as the Effective Request URI, the response is a representation of the 
     689   resource at the Effective Request URI.</t> 
    686690   <t>If the response has a Content-Location header, and that URI is not the 
    687    same as the request-URI, the response asserts that it is a representation of 
    688    the resource at the Content-Location URI (but it may not be).</t> 
     691   same as the Effective Request URI, the response asserts that it is a 
     692   representation of the resource at the Content-Location URI (but it may not 
     693   be).</t> 
    689694   <t>Otherwise, the response is a representation of an anonymous (i.e., 
    690695   unidentified) resource.</t> 
     
    692697<t> 
    693698  <cref anchor="TODO-req-uri"> 
    694    Note that "request-URI" is used here; however, we need to come up with a 
    695    term to denote "the URI that can be inferred from examining the 
    696    request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />). 
    697    Also, the comparison function is going to have to be defined somewhere, 
     699   The comparison function is going to have to be defined somewhere, 
    698700   because we already need to compare URIs for things like cache invalidation.</cref> 
    699701</t> 
     
    761763   The OPTIONS method represents a request for information about the 
    762764   communication options available on the request/response chain 
    763    identified by the request-target. This method allows the client to 
     765   identified by the Effective Request URI. This method allows the client to 
    764766   determine the options and/or requirements associated with a resource, 
    765767   or the capabilities of a server, without implying a resource action 
     
    826828   The GET method means retrieve whatever information (in the form of an 
    827829   entity) currently corresponds to the resource identified by the 
    828    request-target. 
     830   Effective Request URI. 
    829831</t> 
    830832<t>    
    831    If the request-target identifies a data-producing process, it is the 
     833   If the Effective Request URI identifies a data-producing process, it is the 
    832834   produced data which shall be returned as the entity in the response and not 
    833835   the source text of the process, unless that text happens to be the output of 
     
    894896   The POST method is used to request that the origin server accept the 
    895897   entity enclosed in the request as data to be processed by the resource 
    896    identified by the request-target in the Request-Line. POST is designed 
     898   identified by the Effective Request URI. POST is designed 
    897899   to allow a uniform method to cover the following functions: 
    898900  <list style="symbols"> 
     
    915917<t> 
    916918   The actual function performed by the POST method is determined by the 
    917    server and is usually dependent on the request-target. 
     919   server and is usually dependent on the Effective Request URI. 
    918920</t> 
    919921<t> 
     
    943945<t> 
    944946   The PUT method requests that the enclosed entity be stored at the 
    945    supplied request-target. If the request-target refers to an already 
     947   Effective Request URI. If the Effective Request URI refers to an already 
    946948   existing resource, the enclosed entity &SHOULD; be considered as a 
    947    modified version of the one residing on the origin server. If the 
    948    request-target does not point to an existing resource, and that URI is 
     949   modified version of the one residing on the origin server. Otherwise, if the 
     950   Effective Request URI does not point to an existing resource, and that URI is 
    949951   capable of being defined as a new resource by the requesting user 
    950    agent, the origin server can create the resource with that URI. If a 
    951    new resource is created at the request-target, the origin server &MUST; 
    952    inform the user agent 
     952   agent, the origin server can create the resource with that URI. 
     953</t> 
     954<t>    
     955   If a new resource is created at the Effective Request URI, the origin 
     956   server &MUST; inform the user agent 
    953957   via the 201 (Created) response. If an existing resource is modified, 
    954958   either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent 
    955    to indicate successful completion of the request. If the resource 
    956    could not be created or modified with the request-target, an appropriate 
    957    error response &SHOULD; be given that reflects the nature of the 
    958    problem. The recipient of the entity &MUST-NOT; ignore any Content-* 
     959   to indicate successful completion of the request. 
     960</t> 
     961<t>    
     962   If the resource could not be created or modified with the Effective Request  
     963   URI, an appropriate error response &SHOULD; be given that reflects the nature 
     964   of the problem. The recipient of the entity &MUST-NOT; ignore any Content-* 
    959965   headers (headers starting with the prefix "Content-") that it does 
    960966   not understand or implement 
     
    962968</t> 
    963969<t> 
    964    If the request passes through a cache and the request-target identifies 
    965    one or more currently cached entities, those entries &SHOULD; be 
     970   If the request passes through a cache and the Effective Request URI 
     971   identifies one or more currently cached entities, those entries &SHOULD; be 
    966972   treated as stale. Responses to this method are not cacheable. 
    967973</t> 
    968974<t> 
    969975   The fundamental difference between the POST and PUT requests is 
    970    reflected in the different meaning of the request-target. The URI in a 
     976   reflected in the different meaning of the Effective Request URI. The URI in a 
    971977   POST request identifies the resource that will handle the enclosed 
    972978   entity. That resource might be a data-accepting process, a gateway to 
     
    10031009<t> 
    10041010   The DELETE method requests that the origin server delete the resource 
    1005    identified by the request-target. This method &MAY; be overridden by human 
    1006    intervention (or other means) on the origin server. The client cannot 
     1011   identified by the Effective Request URI. This method &MAY; be overridden by 
     1012   human intervention (or other means) on the origin server. The client cannot 
    10071013   be guaranteed that the operation has been carried out, even if the 
    10081014   status code returned from the origin server indicates that the action 
     
    10191025</t> 
    10201026<t> 
    1021    If the request passes through a cache and the request-target identifies 
    1022    one or more currently cached entities, those entries &SHOULD; be 
     1027   If the request passes through a cache and the Effective Request URI 
     1028   identifies one or more currently cached entities, those entries &SHOULD; be 
    10231029   treated as stale. Responses to this method are not cacheable. 
    10241030</t> 
     
    13311337   future references to this resource &SHOULD; use one of the returned 
    13321338   URIs.  Clients with link editing capabilities ought to automatically 
    1333    re-link references to the request-target to one or more of the new 
     1339   re-link references to the Effective Request URI to one or more of the new 
    13341340   references returned by the server, where possible. This response is 
    13351341   cacheable unless indicated otherwise. 
     
    13641370   The requested resource resides temporarily under a different URI. 
    13651371   Since the redirection might be altered on occasion, the client &SHOULD; 
    1366    continue to use the request-target for future requests.  This response 
     1372   continue to use the Effectice Request URI for future requests.  This response 
    13671373   is only cacheable if indicated by a Cache-Control or Expires header 
    13681374   field. 
     
    14771483   The requested resource resides temporarily under a different URI. 
    14781484   Since the redirection &MAY; be altered on occasion, the client &SHOULD; 
    1479    continue to use the request-target for future requests.  This response 
     1485   continue to use the Effective Request URI for future requests.  This response 
    14801486   is only cacheable if indicated by a Cache-Control or Expires header 
    14811487   field. 
     
    15671573  <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/> 
    15681574<t> 
    1569    The server has not found anything matching the request-target. No 
     1575   The server has not found anything matching the Effective Request URI. No 
    15701576   indication is given of whether the condition is temporary or 
    15711577   permanent. The 410 (Gone) status code &SHOULD; be used if the server 
     
    15831589<t> 
    15841590   The method specified in the Request-Line is not allowed for the 
    1585    resource identified by the request-target. The response &MUST; include an 
     1591   resource identified by the Effective Request URI. The response &MUST; include an 
    15861592   Allow header containing a list of valid methods for the requested 
    15871593   resource. 
     
    16741680   forwarding address is known. This condition is expected to be 
    16751681   considered permanent. Clients with link editing capabilities &SHOULD; 
    1676    delete references to the request-target after user approval. If the 
     1682   delete references to the Effective Request URI after user approval. If the 
    16771683   server does not know, or has no facility to determine, whether or not 
    16781684   the condition is permanent, the status code 404 (Not Found) &SHOULD; be 
     
    17361742  <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/> 
    17371743<t> 
    1738    The server is refusing to service the request because the request-target 
     1744   The server is refusing to service the request because the Effective Request URI 
    17391745   is longer than the server is willing to interpret. This rare 
    17401746   condition is only likely to occur when a client has improperly 
     
    17441750   itself), or when the server is under attack by a client attempting to 
    17451751   exploit security holes present in some servers using fixed-length 
    1746    buffers for reading or manipulating the request-target. 
     1752   buffers for reading or manipulating the Effective Request URI. 
    17471753</t> 
    17481754</section> 
     
    18961902<t> 
    18971903   The "Allow" response-header field lists the set of methods advertised as 
    1898    supported by the resource identified by the request-target. The purpose of 
     1904   supported by the resource identified by the Effective Request URI. The purpose of 
    18991905   this field is strictly to inform the recipient of valid methods 
    19001906   associated with the resource. 
     
    21292135<t> 
    21302136   The "Referer" [sic] request-header field allows the client to specify the 
    2131    URI of the resource from which the request-target was obtained (the 
     2137   URI of the resource from which the Effective Request URI was obtained (the 
    21322138   "referrer", although the header field is misspelled.). 
    21332139</t> 
     
    21412147</t> 
    21422148<t> 
    2143    If the request-target was obtained from a source that does not have its own 
     2149   If the Effective Request URI was obtained from a source that does not have its own 
    21442150   URI (e.g., input from the user keyboard), the Referer field &MUST; either be 
    21452151   sent with the value "about:blank", or not be sent at all. Note that this 
     
    21582164<t> 
    21592165   If the field value is a relative URI, it &SHOULD; be interpreted 
    2160    relative to the request-target. The URI &MUST-NOT; include a fragment. See 
     2166   relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See 
    21612167   <xref target="encoding.sensitive.information.in.uris"/> for security considerations. 
    21622168</t> 
     
    27022708</t> 
    27032709<t> 
    2704    Authors of services should not use 
    2705    GET-based forms for the submission of sensitive data because that 
    2706    data will be encoded in the Request-target. Many existing 
    2707    servers, proxies, and user agents log or display the Request-target in 
    2708    places where it might be visible to third parties. Such services can 
     2710   Authors of services should not use GET-based forms for the submission of 
     2711   sensitive data because that data will be encoded in the request-target. Many 
     2712   existing servers, proxies, and user agents log or display the request-target 
     2713   in places where it might be visible to third parties. Such services can 
    27092714   use POST-based form submission instead. 
    27102715</t> 
     
    37813786      "Location header payload handling" 
    37823787    </t> 
     3788    <t> 
     3789      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 
     3790      "Term for the requested resource's URI" 
     3791    </t> 
    37833792  </list> 
    37843793</t> 
  • draft-ietf-httpbis/latest/p3-payload.html

    r814 r823  
    401401      <meta name="dct.creator" content="Reschke, J. F."> 
    402402      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 
    403       <meta name="dct.issued" scheme="ISO8601" content="2010-05-01"> 
     403      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 
    404404      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    405405      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> 
     
    427427            </tr> 
    428428            <tr> 
    429                <td class="left">Expires: November 2, 2010</td> 
     429               <td class="left">Expires: November 27, 2010</td> 
    430430               <td class="right">J. Mogul</td> 
    431431            </tr> 
     
    484484            <tr> 
    485485               <td class="left"></td> 
    486                <td class="right">May 1, 2010</td> 
     486               <td class="right">May 26, 2010</td> 
    487487            </tr> 
    488488         </tbody> 
     
    510510         in progress”. 
    511511      </p> 
    512       <p>This Internet-Draft will expire in November 2, 2010.</p> 
     512      <p>This Internet-Draft will expire in November 27, 2010.</p> 
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    514514      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    12231223      </p> 
    12241224      <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip 
    1225 </pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the request-target. Typically, the entity-body is stored 
    1226          with this encoding and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 
     1225</pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Typically, the entity-body is stored with this encoding and is only decoded before rendering or analogous usage. However, 
     1226         a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control 
    12271227         directive is present in the message. 
    12281228      </p> 
     
    12731273  <a href="#header.content-location" class="smpl">Content-Location-v</a> = 
    12741274                    <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 
    1275 </pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of 
    1276          the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-target if the desire is to identify the source of that particular entity. 
     1275</pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. 
     1276         Future requests <em class="bcp14">MAY</em> may be addressed to the Content-Location URI if the desire is to identify the source of that particular entity. 
    12771277      </p> 
    12781278      <p id="rfc.section.5.7.p.5"> <a href="p2-semantics.html#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> describes how clients may process the Content-Location header field. 
     
    12821282         entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.6</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 
    12831283      </p> 
    1284       <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the request-target.</p> 
     1284      <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Effective Request URI.</p> 
    12851285      <p id="rfc.section.5.7.p.8">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p> 
    12861286      <div id="rfc.iref.c.10"></div> 
     
    14501450                  <td class="left">compress</td> 
    14511451                  <td class="left">UNIX "compress" program method</td> 
    1452                   <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>  
     1452                  <td class="left"> <a href="p1-messaging.html#compress.coding" title="Compress Coding">Section 6.2.2.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>  
    14531453                  </td> 
    14541454               </tr> 
     
    14571457                  <td class="left">"deflate" compression mechanism (<a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>) used inside the "zlib" data format (<a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a>) 
    14581458                  </td> 
    1459                   <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>  
     1459                  <td class="left"> <a href="p1-messaging.html#deflate.coding" title="Deflate Coding">Section 6.2.2.2</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>  
    14601460                  </td> 
    14611461               </tr> 
     
    14631463                  <td class="left">gzip</td> 
    14641464                  <td class="left">Same as GNU zip <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a></td> 
    1465                   <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>  
     1465                  <td class="left"> <a href="p1-messaging.html#gzip.coding" title="Gzip Coding">Section 6.2.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>  
    14661466                  </td> 
    14671467               </tr> 
     
    17301730      </p> 
    17311731      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2> 
    1732       <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary. 
     1732      <p id="rfc.section.A.3.p.1">HTTP/1.1 uses a restricted set of date formats (<a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) to simplify the process of date comparison. Proxies and gateways from other protocols <em class="bcp14">SHOULD</em> ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary. 
    17331733      </p> 
    17341734      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2> 
     
    17471747      </p> 
    17481748      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2> 
    1749       <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 
     1749      <p id="rfc.section.A.6.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 9.7</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol. 
    17501750      </p> 
    17511751      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> 
     
    17921792      <p id="rfc.section.C.1.p.1">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow 
    17931793         for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are 
    1794          computed. (<a href="#entity.length" title="Entity Length">Section&nbsp;3.2.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 
     1794         computed. (<a href="#entity.length" title="Entity Length">Section&nbsp;3.2.2</a>, see also <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a> and <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 
    17951795      </p> 
    17961796      <p id="rfc.section.C.1.p.2">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.3" title="Accept-Charset">Section&nbsp;5.2</a>) 
     
    20522052         </li> 
    20532053         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure" 
     2054         </li> 
     2055      </ul> 
     2056      <p id="rfc.section.E.11.p.2">Partly resolved issues: </p> 
     2057      <ul> 
     2058         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI" 
    20542059         </li> 
    20552060      </ul> 
     
    21922197            </li> 
    21932198            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 
    2194                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a>, <a class="iref" href="#rfc.xref.Part1.27">C.1</a><ul class="ind"> 
     2199                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3.2.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a>, <a class="iref" href="#rfc.xref.Part1.22">5.5</a>, <a class="iref" href="#rfc.xref.Part1.23">5.7</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a>, <a class="iref" href="#rfc.xref.Part1.26">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.27">A.3</a>, <a class="iref" href="#rfc.xref.Part1.28">A.6</a>, <a class="iref" href="#rfc.xref.Part1.29">C.1</a><ul class="ind"> 
    21952200                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a></li> 
    21962201                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a></li> 
     
    21992204                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3.2</a></li> 
    22002205                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">3.2.2</a></li> 
    2201                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">A.3</a></li> 
     2206                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.22">5.5</a>, <a class="iref" href="#rfc.xref.Part1.23">5.7</a></li> 
     2207                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">A.3</a></li> 
    22022208                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li> 
    2203                         <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a></li> 
     2209                        <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li> 
    22042210                        <li class="indline1"><em>Section 6.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li> 
    2205                         <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a></li> 
    2206                         <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li> 
     2211                        <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">6.2</a></li> 
     2212                        <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">6.2</a></li> 
    22072213                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.20">5.1</a>, <a class="iref" href="#rfc.xref.Part1.21">5.3</a></li> 
    22082214                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a></li> 
    2209                         <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">A.6</a></li> 
     2215                        <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.28">A.6</a></li> 
    22102216                     </ul> 
    22112217                  </li> 
  • draft-ietf-httpbis/latest/p3-payload.xml

    r814 r823  
    3333  <!ENTITY qvalue                   "<xref target='Part1' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3434  <!ENTITY uri                      "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     35  <!ENTITY effective-request-uri    "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3536  <!ENTITY compression-codings      "<xref target='Part1' x:rel='#compression.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    3637  <!ENTITY transfer-codings         "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     
    13381339<t> 
    13391340   The content-coding is a characteristic of the entity identified by 
    1340    the request-target. Typically, the entity-body is stored with this 
     1341   the Effective Request URI (&effective-request-uri;). Typically, the entity-body is stored with this 
    13411342   encoding and is only decoded before rendering or analogous usage. 
    13421343   However, a non-transparent proxy &MAY; modify the content-coding if the 
     
    14391440</artwork></figure> 
    14401441<t> 
    1441    The Content-Location value is not a replacement for the original 
    1442    requested URI; it is only a statement of the location of the resource 
     1442   The Content-Location value is not a replacement for the Effective 
     1443   Request URI (&effective-request-uri;); it is only a statement of the location of the resource 
    14431444   corresponding to this particular entity at the time of the request. 
    1444    Future requests &MAY; specify the Content-Location URI as the request-target 
     1445   Future requests &MAY; may be addressed to the Content-Location URI 
    14451446   if the desire is to identify the source of that particular 
    14461447   entity. 
     
    14581459<t> 
    14591460   If the Content-Location is a relative URI, the relative URI is 
    1460    interpreted relative to the request-target. 
     1461   interpreted relative to the Effective Request URI. 
    14611462</t> 
    14621463<t> 
     
    31503151  </list> 
    31513152</t> 
     3153<t> 
     3154  Partly resolved issues: 
     3155  <list style="symbols">  
     3156    <t> 
     3157      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 
     3158      "Term for the requested resource's URI" 
     3159    </t> 
     3160  </list> 
     3161</t> 
    31523162</section> 
    31533163 
  • draft-ietf-httpbis/latest/p6-cache.html

    r817 r823  
    402402      <meta name="dct.creator" content="Reschke, J. F."> 
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-05-07"> 
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> 
     
    428428            </tr> 
    429429            <tr> 
    430                <td class="left">Expires: November 8, 2010</td> 
     430               <td class="left">Expires: November 27, 2010</td> 
    431431               <td class="right">J. Mogul</td> 
    432432            </tr> 
     
    489489            <tr> 
    490490               <td class="left"></td> 
    491                <td class="right">May 7, 2010</td> 
     491               <td class="right">May 26, 2010</td> 
    492492            </tr> 
    493493         </tbody> 
     
    515515         in progress”. 
    516516      </p> 
    517       <p>This Internet-Draft will expire in November 8, 2010.</p> 
     517      <p>This Internet-Draft will expire in November 27, 2010.</p> 
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    759759      </p> 
    760760      <ul> 
    761          <li>The presented Request-URI and that of the stored response match (<span class="comment" id="TODO-Request-URI">[<a href="#TODO-Request-URI" class="smpl">TODO-Request-URI</a>: Need to find a new term for this, as Part 1 doesn't define Request-URI anymore; the new term request-target does not work 
    762                for this. (see &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;)]</span>), and 
     761         <li>The presented Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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 that of the stored response match, and 
    763762         </li> 
    764763         <li>the request method associated with the stored response allows it to be used for the presented request, and</li> 
     
    860859         <li>HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response 
    861860            was generated. The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations. 
    862             See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</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> for the definition of the Date header, and for requirements regarding responses without a Date response header. 
     861            See <a href="p1-messaging.html#header.date" title="Date">Section 9.3</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> for the definition of the Date header, and for requirements regarding responses without a Date response header. 
    863862         </li> 
    864863      </ul> 
     
    936935      <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date. 
    937936      </p> 
    938       <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URI as well as the URI(s) in the Location and Content-Location headers (if present):  
     937      <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) as well as the URI(s) in the Location and Content-Location headers (if present):  
    939938      </p> 
    940939      <ul> 
     
    943942         <li>POST</li> 
    944943      </ul> 
    945       <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Request-URI. This helps prevent denial of service 
    946          attacks. 
     944      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks. 
    947945      </p> 
    948946      <p id="rfc.section.2.5.p.4"> <span class="comment" id="TODO-def-host-part">[<a href="#TODO-def-host-part" class="smpl">TODO-def-host-part</a>: "host part" needs to be specified better.]</span>  
    949947      </p> 
    950       <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI. 
    951       </p> 
    952       <p id="rfc.section.2.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Request-URI, or will mark these 
    953          as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request. 
     948      <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
     949      </p> 
     950      <p id="rfc.section.2.5.p.6">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will 
     951         mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request. 
    954952      </p> 
    955953      <p id="rfc.section.2.5.p.7">Note that this does not guarantee that all appropriate responses are invalidated. For example, the request that caused the 
     
    967965      <ul> 
    968966         <li>adding or removing whitespace, where allowed in the header's syntax</li> 
    969          <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</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>) 
     967         <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 
    970968         </li> 
    971969         <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification 
     
    12531251         that time. 
    12541252      </p> 
    1255       <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 
     1253      <p id="rfc.section.3.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format. 
    12561254      </p> 
    12571255      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.expires" class="smpl">Expires</a>   = "Expires" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expires" class="smpl">Expires-v</a> 
     
    18731871         </li> 
    18741872      </ul> 
     1873      <p id="rfc.section.C.11.p.2">Partly resolved issues: </p> 
     1874      <ul> 
     1875         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI" 
     1876         </li> 
     1877      </ul> 
    18751878      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 
    18761879      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a>  
     
    20102013            </li> 
    20112014            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 
    2012                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind"> 
     2015                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a>, <a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.11">2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.3.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.5</a>, <a class="iref" href="#rfc.xref.Part1.14">2.5</a>, <a class="iref" href="#rfc.xref.Part1.15">2.5</a>, <a class="iref" href="#rfc.xref.Part1.16">2.6</a>, <a class="iref" href="#rfc.xref.Part1.17">3.3</a>, <a class="iref" href="#Part1"><b>8.1</b></a><ul class="ind"> 
    20132016                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a></li> 
    20142017                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.4.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.4.1</a></li> 
    20152018                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.4.2</a></li> 
    2016                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.6</a></li> 
    2017                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.13">3.3</a></li> 
    2018                         <li class="indline1"><em>Section 9.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">2.3.2</a></li> 
     2019                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.16">2.6</a></li> 
     2020                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.5</a>, <a class="iref" href="#rfc.xref.Part1.14">2.5</a>, <a class="iref" href="#rfc.xref.Part1.15">2.5</a></li> 
     2021                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">1.4.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.3</a></li> 
     2022                        <li class="indline1"><em>Section 9.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.3.2</a></li> 
    20192023                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.4.2</a></li> 
    20202024                     </ul> 
  • draft-ietf-httpbis/latest/p6-cache.xml

    r817 r823  
    1818  <!ENTITY basic-rules                 "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    1919  <!ENTITY uri                         "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     20  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    2021  <!ENTITY messaging                   "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    2122  <!ENTITY conditional                 "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     
    478479  For a presented request, a cache &MUST-NOT; return a stored response, unless:  
    479480  <list style="symbols"> 
    480     <t>The presented Request-URI and that of the stored response match 
    481       (<cref anchor="TODO-Request-URI">Need to find a new term for this, as Part 
    482       1 doesn't define Request-URI anymore; the new term request-target does not 
    483       work for this. (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />)</cref>), and</t> 
     481    <t>The presented Effective Request URI (&effective-request-uri;) and that of the stored response match, and</t> 
    484482    <t>the request method associated with the stored response allows it to be  
    485483      used for the presented request, and</t> 
     
    798796</t> 
    799797<t> 
    800   The following HTTP methods &MUST; cause a cache to invalidate the Request-URI as well 
     798  The following HTTP methods &MUST; cause a cache to invalidate the Effective Request URI (&effective-request-uri;) as well 
    801799  as the URI(s) in the Location and Content-Location headers (if present): 
    802800  <list style="symbols"> 
     
    808806<t> 
    809807  An invalidation based on a URI from a Location or Content-Location header &MUST-NOT; 
    810   be performed if the host part of that URI differs from the host part in the Request-URI. 
     808  be performed if the host part of that URI differs from the host part in the Effective Request URI (&effective-request-uri;). 
    811809  This helps prevent denial of service attacks. 
    812810</t> 
     
    816814<t> 
    817815  A cache that passes through requests for methods it does not understand &SHOULD; 
    818   invalidate the Request-URI. 
     816  invalidate the Effective Request URI (&effective-request-uri;). 
    819817</t> 
    820818<t> 
    821819  Here, "invalidate" means that the cache will either remove all stored responses related 
    822   to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation 
     820  to the Effective Request URI, or will mark these as "invalid" and in need of a mandatory validation 
    823821  before they can be returned in response to a subsequent request. 
    824822</t> 
     
    24502448  </list> 
    24512449</t> 
     2450<t> 
     2451  Partly resolved issues: 
     2452  <list style="symbols">  
     2453    <t> 
     2454      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 
     2455      "Term for the requested resource's URI" 
     2456    </t> 
     2457  </list> 
     2458</t> 
    24522459</section> 
    24532460 
  • draft-ietf-httpbis/latest/p7-auth.html

    r814 r823  
    394394      <meta name="dct.creator" content="Reschke, J. F."> 
    395395      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 
    396       <meta name="dct.issued" scheme="ISO8601" content="2010-05-01"> 
     396      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26"> 
    397397      <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 
    398398      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> 
     
    425425            </tr> 
    426426            <tr> 
    427                <td class="left">Expires: November 2, 2010</td> 
     427               <td class="left">Expires: November 27, 2010</td> 
    428428               <td class="right">HP</td> 
    429429            </tr> 
     
    478478            <tr> 
    479479               <td class="left"></td> 
    480                <td class="right">May 1, 2010</td> 
     480               <td class="right">May 26, 2010</td> 
    481481            </tr> 
    482482         </tbody> 
     
    504504         in progress”. 
    505505      </p> 
    506       <p>This Internet-Draft will expire in November 2, 2010.</p> 
     506      <p>This Internet-Draft will expire in November 27, 2010.</p> 
    507507      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 
    508508      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 
     
    657657      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2> 
    658658      <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters 
    659          applicable to the proxy for this request-target. It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 
     659         applicable to the proxy for this Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response. 
    660660      </p> 
    661661      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a>   = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> 
     
    685685      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2> 
    686686      <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s) 
    687          and parameters applicable to the request-target. It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. 
     687         and parameters applicable to the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</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>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages. 
    688688      </p> 
    689689      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>   = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a> 
     
    938938      <p id="rfc.section.C.10.p.1">No significant changes.</p> 
    939939      <h2 id="rfc.section.C.11"><a href="#rfc.section.C.11">C.11</a>&nbsp;<a id="changes.since.09" href="#changes.since.09">Since draft-ietf-httpbis-p7-auth-09</a></h2> 
    940       <p id="rfc.section.C.11.p.1">None yet.</p> 
     940      <p id="rfc.section.C.11.p.1">Partly resolved issues: </p> 
     941      <ul> 
     942         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI" 
     943         </li> 
     944      </ul> 
    941945      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 
    942946      <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.W">W</a>  
     
    982986            </li> 
    983987            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 
    984                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.2</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#Part1"><b>7.1</b></a><ul class="ind"> 
     988                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.2</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">3.2</a>, <a class="iref" href="#rfc.xref.Part1.5">3.4</a>, <a class="iref" href="#Part1"><b>7.1</b></a><ul class="ind"> 
    985989                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.2</a></li> 
    986990                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a></li> 
     991                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.4">3.2</a>, <a class="iref" href="#rfc.xref.Part1.5">3.4</a></li> 
    987992                     </ul> 
    988993                  </li> 
  • draft-ietf-httpbis/latest/p7-auth.xml

    r814 r823  
    1818  <!ENTITY notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    1919  <!ENTITY basic-rules                  "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
     20  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    2021  <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 
    2122]> 
     
    401402   The "Proxy-Authenticate" response-header field consists of a challenge that 
    402403   indicates the authentication scheme and parameters applicable to the proxy 
    403    for this request-target. It &MUST; be included as part 
     404   for this Effective Request URI (&effective-request-uri;). It &MUST; be included as part 
    404405   of a 407 (Proxy Authentication Required) response. 
    405406</t> 
     
    460461   The "WWW-Authenticate" response-header field consists of at least one 
    461462   challenge that indicates the authentication scheme(s) and parameters 
    462    applicable to the request-target. It &MUST; be included in 401 
     463   applicable to the Effective Request URI (&effective-request-uri;). It &MUST; be included in 401 
    463464   (Unauthorized) response messages. 
    464465</t> 
     
    977978<section title="Since draft-ietf-httpbis-p7-auth-09" anchor="changes.since.09"> 
    978979<t> 
    979   None yet. 
     980  Partly resolved issues: 
     981  <list style="symbols">  
     982    <t> 
     983      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>: 
     984      "Term for the requested resource's URI" 
     985    </t> 
     986  </list> 
    980987</t> 
    981988</section> 
Note: See TracChangeset for help on using the changeset viewer.