Changeset 823

Timestamp:

26/05/10 17:25:13 (12 years ago)

Author:

julian.reschke@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (37 diffs)
• p1-messaging.xml (modified) (2 diffs)
• p2-semantics.html (modified) (38 diffs)
• p2-semantics.xml (modified) (27 diffs)
• p3-payload.html (modified) (16 diffs)
• p3-payload.xml (modified) (5 diffs)
• p6-cache.html (modified) (12 diffs)
• p6-cache.xml (modified) (6 diffs)
• p7-auth.html (modified) (8 diffs)
• p7-auth.xml (modified) (4 diffs)

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

@@ -573 +573 @@
                </li>
                <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></li>
+               <li class="tocline1">4.3&nbsp;&nbsp;&nbsp;<a href="#effective.request.uri">Effective Request URI</a></li>
             </ul>
          </li>
@@ -1384 +1385 @@
          what exact resource is being requested.
       </p>
+      <div id="rfc.iref.e.1"></div>
+      <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>
+      <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
+         other context. The result of this process is the "Effective Request URI".
+      </p>
+      <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>
+      <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
+         Request URI is constructed by concatenating
+      </p>
+      <p id="rfc.section.4.3.p.4"> </p>
+      <ul>
+         <li>the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over SSL/TLS-secured
+            TCP connection,
+         </li>
+         <li>the character sequence "://",</li>
+         <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
+         </li>
+         <li>the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*".</li>
+      </ul>
+      <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p>
+      <div id="rfc.figure.u.40"></div> 
+      <p>Example 1: the Effective Request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
+Host: www.example.org:8080
+</pre>  <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus
+         the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html".
+      </p> 
+      <div id="rfc.figure.u.41"></div> 
+      <p>Example 2: the Effective Request URI for the message</p>  <pre class="text">GET * HTTP/1.1
+Host: www.example.org
+</pre>  <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org",
+         thus "https://www.example.org".
+      </p> 
+      <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 "/".
+      </p>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
       <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
-      <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>
+      <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>
                   *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.5</a>
                    / <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>
@@ -1397 +1432 @@
          CRLF sequence.
       </p>
-      <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>
+      <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>
 </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>
       <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
@@ -1414 +1449 @@
          <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
       </ul>
-      <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>
+      <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>
   <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> )
 </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>
@@ -1421 +1456 @@
       <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>:
       </p>
-      <div id="rfc.figure.u.43"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
+      <div id="rfc.figure.u.45"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
 </pre><p id="rfc.section.6.1.p.4">The other formats are described here only for compatibility with obsolete implementations.</p>
-      <div id="rfc.figure.u.44"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
+      <div id="rfc.figure.u.46"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
 Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
 </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.
@@ -1431 +1466 @@
          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.
       </p>
-      <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>
+      <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>
 </pre><div id="preferred.date.format">
          <p id="rfc.section.6.1.p.9">                    Preferred format:</p>
       </div>
-      <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>
+      <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>
 
   <a href="#preferred.date.format" class="smpl">day-name</a>     = %x4D.6F.6E ; "Mon", case-sensitive
@@ -1476 +1511 @@
          <p id="rfc.section.6.1.p.12">                Obsolete formats:</p>
       </div>
-      <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> 
-</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>
+      <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> 
+</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>
   <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>
                  ; day-month-year (e.g., 02-Jun-82)
@@ -1488 +1523 @@
          / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
          / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
-</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>
+</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>
   <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> ))
                  ; month day (e.g., Jun  2)
@@ -1506 +1541 @@
          is a property of the message, not of the original entity.
       </p>
-      <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>
+      <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>
                           / "compress" ; <a href="#compress.coding" title="Compress Coding">Section&nbsp;6.2.2.1</a>
                           / "deflate" ; <a href="#deflate.coding" title="Deflate Coding">Section&nbsp;6.2.2.2</a>
@@ -1515 +1550 @@
          <p id="rfc.section.6.2.p.3">      Parameters are in the form of attribute/value pairs.</p>
       </div>
-      <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>
+      <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>
   <a href="#rule.parameter" class="smpl">attribute</a>               = <a href="#rule.token.separators" class="smpl">token</a>
   <a href="#rule.parameter" class="smpl">value</a>                   = <a href="#rule.token.separators" class="smpl">word</a>
@@ -1537 +1572 @@
          necessary for the recipient to verify that it has received the full message.
       </p>
-      <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>
+      <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>
                    <a href="#chunked.encoding" class="smpl">last-chunk</a>
                    <a href="#chunked.encoding" class="smpl">trailer-part</a>
@@ -1580 +1615 @@
       </p>
       <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>
-      <div id="rfc.figure.u.53"></div><pre class="text">  length := 0
+      <div id="rfc.figure.u.55"></div><pre class="text">  length := 0
   read chunk-size, chunk-ext (if any) and CRLF
   while (chunk-size &gt; 0) {
@@ -1649 +1684 @@
          By convention, the products are listed in order of their significance for identifying the application.
       </p>
-      <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>]
+      <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>]
   <a href="#product.tokens" class="smpl">product-version</a> = <a href="#rule.token.separators" class="smpl">token</a>
 </pre><p id="rfc.section.6.3.p.3">Examples:</p>
-      <div id="rfc.figure.u.55"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+      <div id="rfc.figure.u.57"></div><pre class="text">  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
   Server: Apache/0.8.4
 </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).
@@ -1661 +1696 @@
          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.
       </p>
-      <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> ] )
+      <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> ] )
                  / ( "1" [ "." 0*3("0") ] )
 </pre><div class="note" id="rfc.section.6.4.p.3"> 
@@ -1945 +1980 @@
       </p>
       <p id="rfc.section.9.1.p.2">The Connection header's value has the following grammar:</p>
-      <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>
+      <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>
   <a href="#header.connection" class="smpl">Connection-v</a>     = 1#<a href="#header.connection" class="smpl">connection-token</a>
   <a href="#header.connection" class="smpl">connection-token</a> = <a href="#rule.token.separators" class="smpl">token</a>
@@ -1958 +1993 @@
          of the response. For example,
       </p>
-      <div id="rfc.figure.u.58"></div><pre class="text">  Connection: close
+      <div id="rfc.figure.u.60"></div><pre class="text">  Connection: close
 </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.
       </p>
@@ -1974 +2009 @@
          to the HEAD method, it indicates the size of the entity-body that would have been sent had the request been a GET.
       </p>
-      <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>
+      <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>
   <a href="#header.content-length" class="smpl">Content-Length-v</a> = 1*<a href="#core.rules" class="smpl">DIGIT</a>
 </pre><p id="rfc.section.9.2.p.3">An example is</p>
-      <div id="rfc.figure.u.60"></div><pre class="text">  Content-Length: 3495
+      <div id="rfc.figure.u.62"></div><pre class="text">  Content-Length: 3495
 </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>.
       </p>
@@ -1992 +2027 @@
          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.
       </p>
-      <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>
+      <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>
   <a href="#header.date" class="smpl">Date-v</a> = <a href="#date.time.formats.full.date" class="smpl">HTTP-date</a>
 </pre><p id="rfc.section.9.3.p.3">An example is</p>
-      <div id="rfc.figure.u.62"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
+      <div id="rfc.figure.u.64"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
 </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: 
       </p>
@@ -2033 +2068 @@
          resource (generally an http URI, as described in <a href="#http.uri" title="http URI scheme">Section&nbsp;2.6.1</a>).
       </p>
-      <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>
+      <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>
   <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>
 </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
          URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
       </p>
-      <div id="rfc.figure.u.64"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
+      <div id="rfc.figure.u.66"></div><pre class="text2">GET /pub/WWW/ HTTP/1.1
 Host: www.example.org
 </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
@@ -2055 +2090 @@
          accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
       </p>
-      <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>
+      <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>
   <a href="#header.te" class="smpl">TE-v</a>      = #<a href="#header.te" class="smpl">t-codings</a>
   <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> ] )
@@ -2064 +2099 @@
       </p>
       <p id="rfc.section.9.5.p.5">Examples of its use are:</p>
-      <div id="rfc.figure.u.66"></div><pre class="text">  TE: deflate
+      <div id="rfc.figure.u.68"></div><pre class="text">  TE: deflate
   TE:
   TE: trailers, deflate;q=0.5
@@ -2101 +2136 @@
          with chunked transfer-coding.
       </p>
-      <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>
+      <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>
   <a href="#header.trailer" class="smpl">Trailer-v</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
 </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
@@ -2122 +2157 @@
          are not.
       </p>
-      <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>
+      <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>
                         <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a>
   <a href="#header.transfer-encoding" class="smpl">Transfer-Encoding-v</a> = 1#<a href="#transfer.codings" class="smpl">transfer-coding</a>
 </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:
       </p>
-      <div id="rfc.figure.u.69"></div><pre class="text">  Transfer-Encoding: chunked
+      <div id="rfc.figure.u.71"></div><pre class="text">  Transfer-Encoding: chunked
 </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.
       </p>
@@ -2138 +2173 @@
          to.
       </p>
-      <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>
+      <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>
   <a href="#header.upgrade" class="smpl">Upgrade-v</a> = 1#<a href="#product.tokens" class="smpl">product</a>
 </pre><p id="rfc.section.9.8.p.3">For example,</p>
-      <div id="rfc.figure.u.71"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+      <div id="rfc.figure.u.73"></div><pre class="text">  Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
 </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
          protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP
@@ -2194 +2229 @@
          of all senders along the request/response chain.
       </p>
-      <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>
+      <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>
   <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>
                           [ <a href="#rule.whitespace" class="smpl">RWS</a> <a href="#rule.comment" class="smpl">comment</a> ] )
@@ -2219 +2254 @@
          server at www.example.com. The request received by www.example.com would then have the following Via header field:
       </p>
-      <div id="rfc.figure.u.73"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
+      <div id="rfc.figure.u.75"></div><pre class="text">  Via: 1.0 fred, 1.1 p.example.net (Apache/1.1)
 </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.
       </p>
@@ -2225 +2260 @@
          For example,
       </p>
-      <div id="rfc.figure.u.74"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+      <div id="rfc.figure.u.76"></div><pre class="text">  Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
 </pre><p id="rfc.section.9.9.p.12">could be collapsed to</p>
-      <div id="rfc.figure.u.75"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+      <div id="rfc.figure.u.77"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
 </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
          by pseudonyms. Applications <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
@@ -2272 +2307 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.1" title="Host">Section&nbsp;9.4</a> 
+                  <td class="left"> <a href="#header.host" id="rfc.xref.header.host.2" title="Host">Section&nbsp;9.4</a> 
                   </td>
                </tr>
@@ -2865 +2900 @@
       <p id="rfc.section.B.1.p.1">This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.</p>
       <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>
-      <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.
+      <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.
       </p>
       <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
@@ -2947 +2982 @@
       </p>
       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
-      <div id="rfc.figure.u.76"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
+      <div id="rfc.figure.u.78"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
 
 <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
@@ -3138 +3173 @@
 
 <a href="#preferred.date.format" class="smpl">year</a> = 4DIGIT
-</pre> <div id="rfc.figure.u.77"></div>
+</pre> <div id="rfc.figure.u.79"></div>
       <p>ABNF diagnostics:</p><pre class="inline">; Chunked-Body defined but not used
 ; Content-Length defined but not used
@@ -3396 +3431 @@
          </li>
       </ul>
+      <p id="rfc.section.D.11.p.2">Partly resolved issues: </p>
+      <ul>
+         <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"
+         </li>
+      </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
-      <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> 
+      <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> 
       </p>
       <div class="print2col">
@@ -3432 +3472 @@
                   <li class="indline1">deflate (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li>
                   <li class="indline1">downstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
+               </ul>
+            </li>
+            <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind">
+                  <li class="indline1">Effective Request URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li>
                </ul>
             </li>
@@ -3570 +3614 @@
                         <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>
                         <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>
-                        <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>
+                        <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>
                         <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>
                         <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>
@@ -3578 +3622 @@
                      </ul>
                   </li>
-                  <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>
+                  <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>
                   <li class="indline1">http URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.1"><b>2.6.1</b></a></li>
                   <li class="indline1">https URI scheme&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.2">2.6.2</a></li>
@@ -3679 +3723 @@
                   <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>
                   <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>
-                  <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">
+                  <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">
                         <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>
                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.8">2.6</a></li>
@@ -3689 +3733 @@
                         <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.5">2.6</a></li>
                         <li class="indline1"><em>Section 4.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.7">2.6</a></li>
-                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.6">2.6</a></li>
+                        <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>
                         <li class="indline1"><em>Section 6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3986.15">2.6.3</a></li>
                      </ul>

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

@@ -1595 +1595 @@
    exact resource is being requested.
 </t>
+</section>
+
+<section title="Effective Request URI" anchor="effective.request.uri">
+  <iref primary="true" item="Effective Request URI"/>
+<t>
+   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
+   for the resource they are intended for; instead, the value needs to be inferred from the
+   request-target, Host header and other context. The result of this process is
+   the "Effective Request URI".
+</t>
+<t>
+   If the request-target is an absolute-URI, then the Effective Request URI is
+   the request-target.
+</t>
+<t>
+   If the request-target uses the path-absolute (plus optional query) syntax
+   or if it is just the asterisk "*", then the Effective Request URI is
+   constructed by concatenating
+</t>
+<t>
+  <list style="symbols">
+    <t>
+      the scheme name: "http" if the request was received over an insecure
+      TCP connection, or "https" when received over SSL/TLS-secured TCP
+      connection,
+    </t>
+    <t>
+      the character sequence "://",
+    </t>
+    <t>
+      the authority component, as specified in the Host header
+      (<xref target="header.host"/>) and determined by the rules in
+      <xref target="the.resource.identified.by.a.request"/>,
+      <cref anchor="effrequri-nohost" source="jre">Do we need to include the handling of missing hosts in HTTP/1.0 messages, as
+      described in <xref target="the.resource.identified.by.a.request"/>?</cref>
+      and
+    </t>
+    <t>
+      the request-target obtained from the Request-Line, unless the
+      request-target is just the asterisk "*".
+    </t>
+  </list>
+</t>
+<t>
+   Otherwise, when request-target uses the authority form, the Effective
+   Request URI is undefined.
+</t>
+<figure>
+<preamble>
+   Example 1: the Effective Request URI for the message
+</preamble> 
+<artwork type="example" x:indent-with="  ">
+GET /pub/WWW/TheProject.html HTTP/1.1
+Host: www.example.org:8080
+</artwork>
+<postamble>
+  (received over an insecure TCP connection) is "http", plus "://", plus the
+  authority component "www.example.org:8080", plus the request-target
+  "/pub/WWW/TheProject.html", thus
+  "http://www.example.org:8080/pub/WWW/TheProject.html".
+</postamble>
+</figure>
+<figure>
+<preamble>
+   Example 2: the Effective Request URI for the message
+</preamble> 
+<artwork type="example" x:indent-with="  ">
+GET * HTTP/1.1
+Host: www.example.org
+</artwork>
+<postamble>
+  (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the
+  authority component "www.example.org", thus "https://www.example.org".
+</postamble>
+</figure>
+<t>
+   Effective Request URIs are compared using the rules described in 
+   <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
+   be treated as equivalent to an absolute path of "/".
+</t>  
 </section>
 
@@ -5556 +5636 @@
   </list>
 </t>
+<t>
+  Partly resolved issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
+      "Term for the requested resource's URI"
+    </t>
+  </list>
+</t>
 </section>
 

draft-ietf-httpbis/latest/p2-semantics.html

@@ -403 +403 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-05-07">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -434 +434 @@
             </tr>
             <tr>
-               <td class="left">Expires: November 8, 2010</td>
+               <td class="left">Expires: November 27, 2010</td>
                <td class="right">HP</td>
             </tr>
@@ -487 +487 @@
             <tr>
                <td class="left"></td>
-               <td class="right">May 7, 2010</td>
+               <td class="right">May 26, 2010</td>
             </tr>
          </tbody>
@@ -514 +514 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in November 8, 2010.</p>
+      <p>This Internet-Draft will expire in November 27, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -753 +753 @@
              &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;
 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
-      <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>
+      <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.
+      </p>
       <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>
                  / %x47.45.54               ; "GET", <a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;7.3</a>
@@ -796 +797 @@
                  / <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>
                  / <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>
-                 / <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>
+                 / <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>
                  / <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>
                  / <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>
@@ -806 +807 @@
                  / <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>
                  / <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>
-                 / <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>
+                 / <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>
                  / <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>
 </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
@@ -880 +881 @@
       <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
          Status-Line. These header fields give information about the server and about further access to the resource identified by
-         the request-target.
+         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>).
       </p>
       <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>
@@ -901 +902 @@
          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>.
       </p>
-      <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
+      <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
          safe and proper transfer of the message.
       </p>
@@ -907 +908 @@
       <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p>
       <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>
-      <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
-         always the case. To determine the URI of the resource a response is associated with, the following rules are used (with the
-         first applicable one being selected):
+      <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
+         rules are used (with the first applicable one being selected):
       </p>
       <ol>
          <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource
-            at the request-URI.
+            at the Effective Request URI.
          </li>
          <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
-            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>).
-         </li>
-         <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.
-         </li>
-         <li>If the response has a Content-Location header, and that URI is not the same as the request-URI, the response asserts that
-            it is a representation of the resource at the Content-Location URI (but it may not be).
+            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>).
+         </li>
+         <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
+            of the resource at the Effective Request URI.
+         </li>
+         <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts
+            that it is a representation of the resource at the Content-Location URI (but it may not be).
          </li>
          <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
       </ol>
-      <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
-            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
-            like cache invalidation.]</span> 
+      <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
+            cache invalidation.]</span> 
       </p>
       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
@@ -958 +958 @@
       <div id="rfc.iref.m.1"></div>
       <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
-         chain identified by the request-target. This method allows the client to determine the options and/or requirements associated
-         with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
+         chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements
+         associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
       </p>
       <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p>
@@ -986 +986 @@
       <div id="rfc.iref.m.2"></div>
       <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
-         by the request-target.
-      </p>
-      <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
-         the response and not the source text of the process, unless that text happens to be the output of the process.
+         by the Effective Request URI.
+      </p>
+      <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
+         in the response and not the source text of the process, unless that text happens to be the output of the process.
       </p>
       <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,
@@ -1020 +1020 @@
       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
       <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
-         by the resource identified by the request-target in the Request-Line. POST is designed to allow a uniform method to cover
-         the following functions: 
+         by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the following
+         functions: 
       </p>
       <ul>
@@ -1029 +1029 @@
          <li>Extending a database through an append operation.</li>
       </ul>
-      <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>
+      <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
+         URI.
+      </p>
       <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
          200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity
@@ -1043 +1045 @@
       <div id="rfc.iref.m.5"></div>
       <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
-      <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
-         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
-         resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create
-         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
-         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,
-         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.
-      </p>
-      <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.
-      </p>
-      <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.
-         The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting
+      <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
+         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
+         not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent,
+         the origin server can create the resource with that URI.
+      </p>
+      <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
+         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
+      </p>
+      <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.
+      </p>
+      <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
+         entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
+      </p>
+      <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
+         URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting
          process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request
          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,
          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.
       </p>
-      <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
+      <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
          is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in
          several other URIs being defined by the origin server.
       </p>
-      <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>
-      <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.
+      <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>
+      <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.
       </p>
       <div id="rfc.iref.d.1"></div>
       <div id="rfc.iref.m.6"></div>
       <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
-      <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
+      <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
          has been carried out, even if the status code returned from the origin server indicates that the action has been completed
          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
@@ -1076 +1082 @@
          or 204 (No Content) if the action has been enacted but the response does not include an entity.
       </p>
-      <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.
+      <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
+         entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
       </p>
       <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h2>
@@ -1086 +1093 @@
       </p>
       <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
-         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
+         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
          client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
          infinite loop.
       </p>
-      <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.
+      <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.
       </p>
       <div id="rfc.iref.c.1"></div>
@@ -1117 +1124 @@
       <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
          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
-         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.
+         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.
       </p>
       <div id="rfc.iref.26"></div>
@@ -1228 +1235 @@
       <div id="rfc.iref.s.12"></div>
       <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>
-      <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
-         to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
+      <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
+         Request URI to one or more of the new references returned by the server, where possible. This response is cacheable unless
+         indicated otherwise.
       </p>
       <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).
@@ -1245 +1253 @@
       <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>
       <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
-         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
-         Expires header field.
+         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
+         or Expires header field.
       </p>
       <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).
@@ -1298 +1306 @@
       <div id="rfc.iref.s.18"></div>
       <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>
-      <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
-         Expires header field.
+      <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
+         or Expires header field.
       </p>
       <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
@@ -1341 +1349 @@
       <div id="rfc.iref.s.23"></div>
       <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>
-      <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
+      <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
          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
          and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request
@@ -1349 +1357 @@
       <div id="rfc.iref.s.24"></div>
       <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>
-      <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.
+      <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.
       </p>
       <div id="rfc.iref.48"></div>
@@ -1396 +1404 @@
       <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>
       <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
-         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,
+         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,
          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.
       </p>
@@ -1428 +1436 @@
       <div id="rfc.iref.s.33"></div>
       <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>
-      <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.
+      <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.
          This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
          query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that
          points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present
-         in some servers using fixed-length buffers for reading or manipulating the request-target.
+         in some servers using fixed-length buffers for reading or manipulating the Effective Request URI.
       </p>
       <div id="rfc.iref.57"></div>
@@ -1498 +1506 @@
       <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
          is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
-         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.
+         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.
       </p>
       <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>
@@ -1508 +1516 @@
       <div id="rfc.iref.h.2"></div>
       <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>
-      <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.
-         The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
+      <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
+         Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
       </p>
       <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>
@@ -1543 +1551 @@
       </p>
       <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>
-      <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.
+      <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.
       </p>
       <div id="rfc.iref.f.1"></div>
@@ -1615 +1623 @@
       <div id="rfc.iref.h.7"></div>
       <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>
-      <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
-         was obtained (the "referrer", although the header field is misspelled.).
+      <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
+         URI was obtained (the "referrer", although the header field is misspelled.).
       </p>
       <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.
@@ -1623 +1631 @@
          contain a Referer header field.
       </p>
-      <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
-         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
+      <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),
+         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
          non-HTTP URIs (e.g., FTP).
       </p>
@@ -1631 +1639 @@
 </pre><p id="rfc.section.9.6.p.5">Example:</p>
       <div id="rfc.figure.u.22"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
-</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.
+</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.
       </p>
       <div id="rfc.iref.r.2"></div>
@@ -1655 +1663 @@
       <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>
       <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>
-      <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
+      <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
          identifying the application.
       </p>
@@ -1663 +1671 @@
 </pre><p id="rfc.section.9.8.p.4">Example:</p>
       <div id="rfc.figure.u.27"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
-</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>).
+</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>).
       </p>
       <div class="note" id="rfc.section.9.8.p.7"> 
@@ -1678 +1686 @@
          to avoid particular user agent limitations.
       </p>
-      <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
+      <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
          are listed in order of their significance for identifying the application.
       </p>
@@ -2114 +2122 @@
       </p>
       <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
-         in the Request-target. Many existing servers, proxies, and user agents log or display the Request-target in places where it
+         in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it
          might be visible to third parties. Such services can use POST-based form submission instead.
       </p>
@@ -2282 +2290 @@
       </p>
       <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
-         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>)
+         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>)
       </p>
       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
@@ -2565 +2573 @@
       <ul>
          <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"
+         </li>
+         <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"
          </li>
       </ul>
@@ -2735 +2745 @@
             </li>
             <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
-                  <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">
+                  <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">
                         <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2</a></li>
                         <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>
-                        <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.23">8.5.6</a></li>
+                        <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">8.5.6</a></li>
                         <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>
-                        <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>
-                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">6</a></li>
+                        <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>
+                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">6</a></li>
+                        <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>
                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li>
-                        <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>
-                        <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>
-                        <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">3</a></li>
-                        <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>
-                        <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>
-                        <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">7.8</a></li>
+                        <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>
+                        <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>
+                        <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3</a></li>
+                        <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>
+                        <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>
+                        <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.24">7.8</a></li>
                      </ul>
                   </li>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -27 +27 @@
   <!ENTITY basic-rules                "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY uri                        "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY full-date                  "<xref target='Part1' x:rel='#date.time.formats.full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -423 +424 @@
   <x:anchor-alias value="extension-method"/>
 <t>
-   The Method  token indicates the method to be performed on the
-   resource identified by the request-target. The method is case-sensitive.
+   The Method token indicates the method to be performed on the resource
+   identified by the Effective Request URI (&effective-request-uri;). The
+   method is case-sensitive.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Method"/><iref primary="true" item="Grammar" subitem="extension-method"/>
@@ -621 +623 @@
    information about the response which cannot be placed in the Status-Line.
    These header fields give information about the server and about
-   further access to the resource identified by the request-target.
+   further access to the resource identified by the Effective Request URI
+   (&effective-request-uri;).
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="response-header"/>
@@ -671 +674 @@
 <t>
    In the common case, an HTTP response is a representation of the resource
-   located at the request-URI. However, this is not always the case. To
-   determine the URI of the resource a response is associated with, the
-   following rules are used (with the first applicable one being selected):
+   located at the Effective Request URI (see &effective-request-uri;). However,
+   this is not always the case. To determine the URI of the resource a
+   response is associated with, the following rules are used (with the first
+   applicable one being selected):
 </t>
 <t><list style="numbers">
    <t>If the response status code is 200 or 203 and the request method was GET,
-   the response is a representation of the resource at the request-URI.</t>
+   the response is a representation of the resource at the Effective Request URI.</t>
    <t>If the response status is 204, 206, or 304 and the request method was GET
    or HEAD, the response is a partial representation of the resource at the
-   request-URI (see &caching-combining-headers;).</t>
+   Effective Request URI (see &caching-combining-headers;).</t>
    <t>If the response has a Content-Location header, and that URI is the same
-   as the request-URI <cref anchor="TODO-missref-requri">(see [ref])</cref>, the response is a representation of the
-   resource at the request-URI.</t>
+   as the Effective Request URI, the response is a representation of the
+   resource at the Effective Request URI.</t>
    <t>If the response has a Content-Location header, and that URI is not the
-   same as the request-URI, the response asserts that it is a representation of
-   the resource at the Content-Location URI (but it may not be).</t>
+   same as the Effective Request URI, the response asserts that it is a
+   representation of the resource at the Content-Location URI (but it may not
+   be).</t>
    <t>Otherwise, the response is a representation of an anonymous (i.e.,
    unidentified) resource.</t>
@@ -692 +697 @@
 <t>
   <cref anchor="TODO-req-uri">
-   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 examining the
-   request-target and the Host header." (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />).
-   Also, the comparison function is going to have to be defined somewhere,
+   The comparison function is going to have to be defined somewhere,
    because we already need to compare URIs for things like cache invalidation.</cref>
 </t>
@@ -761 +763 @@
    The OPTIONS method represents a request for information about the
    communication options available on the request/response chain
-   identified by the request-target. This method allows the client to
+   identified by the Effective Request URI. This method allows the client to
    determine the options and/or requirements associated with a resource,
    or the capabilities of a server, without implying a resource action
@@ -826 +828 @@
    The GET method means retrieve whatever information (in the form of an
    entity) currently corresponds to the resource identified by the
-   request-target.
+   Effective Request URI.
 </t>
 <t>   
-   If the request-target identifies a data-producing process, it is the
+   If the Effective Request URI identifies a data-producing process, it is the
    produced data which shall be returned as the entity in the response and not
    the source text of the process, unless that text happens to be the output of
@@ -894 +896 @@
    The POST method is used to request that the origin server accept the
    entity enclosed in the request as data to be processed by the resource
-   identified by the request-target in the Request-Line. POST is designed
+   identified by the Effective Request URI. POST is designed
    to allow a uniform method to cover the following functions:
   <list style="symbols">
@@ -915 +917 @@
 <t>
    The actual function performed by the POST method is determined by the
-   server and is usually dependent on the request-target.
+   server and is usually dependent on the Effective Request URI.
 </t>
 <t>
@@ -943 +945 @@
 <t>
    The PUT method requests that the enclosed entity be stored at the
-   supplied request-target. If the request-target refers to an already
+   Effective Request URI. If the Effective Request URI refers to an already
    existing resource, the enclosed entity &SHOULD; be considered as a
-   modified version of the one residing on the origin server. If the
-   request-target does not point to an existing resource, and that URI is
+   modified version of the one residing on the origin server. Otherwise, if the
+   Effective Request URI does not point to an existing resource, and that URI is
    capable of being defined as a new resource by the requesting user
-   agent, the origin server can create the resource with that URI. If a
-   new resource is created at the request-target, the origin server &MUST;
-   inform the user agent
+   agent, the origin server can create the resource with that URI.
+</t>
+<t>   
+   If a new resource is created at the Effective Request URI, the origin
+   server &MUST; inform the user agent
    via the 201 (Created) response. If an existing resource is modified,
    either the 200 (OK) or 204 (No Content) response codes &SHOULD; be sent
-   to indicate successful completion of the request. If the resource
-   could not be created or modified with the request-target, an appropriate
-   error response &SHOULD; be given that reflects the nature of the
-   problem. The recipient of the entity &MUST-NOT; ignore any Content-*
+   to indicate successful completion of the request.
+</t>
+<t>   
+   If the resource could not be created or modified with the Effective Request 
+   URI, an appropriate error response &SHOULD; be given that reflects the nature
+   of the problem. The recipient of the entity &MUST-NOT; ignore any Content-*
    headers (headers starting with the prefix "Content-") that it does
    not understand or implement
@@ -962 +968 @@
 </t>
 <t>
-   If the request passes through a cache and the request-target identifies
-   one or more currently cached entities, those entries &SHOULD; be
+   If the request passes through a cache and the Effective Request URI
+   identifies one or more currently cached entities, those entries &SHOULD; be
    treated as stale. Responses to this method are not cacheable.
 </t>
 <t>
    The fundamental difference between the POST and PUT requests is
-   reflected in the different meaning of the request-target. The URI in a
+   reflected in the different meaning of the Effective Request URI. The URI in a
    POST request identifies the resource that will handle the enclosed
    entity. That resource might be a data-accepting process, a gateway to
@@ -1003 +1009 @@
 <t>
    The DELETE method requests that the origin server delete the resource
-   identified by the request-target. This method &MAY; be overridden by human
-   intervention (or other means) on the origin server. The client cannot
+   identified by the Effective Request URI. This method &MAY; be overridden by
+   human intervention (or other means) on the origin server. The client cannot
    be guaranteed that the operation has been carried out, even if the
    status code returned from the origin server indicates that the action
@@ -1019 +1025 @@
 </t>
 <t>
-   If the request passes through a cache and the request-target identifies
-   one or more currently cached entities, those entries &SHOULD; be
+   If the request passes through a cache and the Effective Request URI
+   identifies one or more currently cached entities, those entries &SHOULD; be
    treated as stale. Responses to this method are not cacheable.
 </t>
@@ -1331 +1337 @@
    future references to this resource &SHOULD; use one of the returned
    URIs.  Clients with link editing capabilities ought to automatically
-   re-link references to the request-target to one or more of the new
+   re-link references to the Effective Request URI to one or more of the new
    references returned by the server, where possible. This response is
    cacheable unless indicated otherwise.
@@ -1364 +1370 @@
    The requested resource resides temporarily under a different URI.
    Since the redirection might be altered on occasion, the client &SHOULD;
-   continue to use the request-target for future requests.  This response
+   continue to use the Effectice Request URI for future requests.  This response
    is only cacheable if indicated by a Cache-Control or Expires header
    field.
@@ -1477 +1483 @@
    The requested resource resides temporarily under a different URI.
    Since the redirection &MAY; be altered on occasion, the client &SHOULD;
-   continue to use the request-target for future requests.  This response
+   continue to use the Effective Request URI for future requests.  This response
    is only cacheable if indicated by a Cache-Control or Expires header
    field.
@@ -1567 +1573 @@
   <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/>
 <t>
-   The server has not found anything matching the request-target. No
+   The server has not found anything matching the Effective Request URI. No
    indication is given of whether the condition is temporary or
    permanent. The 410 (Gone) status code &SHOULD; be used if the server
@@ -1583 +1589 @@
 <t>
    The method specified in the Request-Line is not allowed for the
-   resource identified by the request-target. The response &MUST; include an
+   resource identified by the Effective Request URI. The response &MUST; include an
    Allow header containing a list of valid methods for the requested
    resource.
@@ -1674 +1680 @@
    forwarding address is known. This condition is expected to be
    considered permanent. Clients with link editing capabilities &SHOULD;
-   delete references to the request-target after user approval. If the
+   delete references to the Effective Request URI after user approval. If the
    server does not know, or has no facility to determine, whether or not
    the condition is permanent, the status code 404 (Not Found) &SHOULD; be
@@ -1736 +1742 @@
   <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
 <t>
-   The server is refusing to service the request because the request-target
+   The server is refusing to service the request because the Effective Request URI
    is longer than the server is willing to interpret. This rare
    condition is only likely to occur when a client has improperly
@@ -1744 +1750 @@
    itself), or when the server is under attack by a client attempting to
    exploit security holes present in some servers using fixed-length
-   buffers for reading or manipulating the request-target.
+   buffers for reading or manipulating the Effective Request URI.
 </t>
 </section>
@@ -1896 +1902 @@
 <t>
    The "Allow" response-header field lists the set of methods advertised as
-   supported by the resource identified by the request-target. The purpose of
+   supported by the resource identified by the Effective Request URI. The purpose of
    this field is strictly to inform the recipient of valid methods
    associated with the resource.
@@ -2129 +2135 @@
 <t>
    The "Referer" [sic] request-header field allows the client to specify the
-   URI of the resource from which the request-target was obtained (the
+   URI of the resource from which the Effective Request URI was obtained (the
    "referrer", although the header field is misspelled.).
 </t>
@@ -2141 +2147 @@
 </t>
 <t>
-   If the request-target was obtained from a source that does not have its own
+   If the Effective Request URI was obtained from a source that does not have its own
    URI (e.g., input from the user keyboard), the Referer field &MUST; either be
    sent with the value "about:blank", or not be sent at all. Note that this
@@ -2158 +2164 @@
 <t>
    If the field value is a relative URI, it &SHOULD; be interpreted
-   relative to the request-target. The URI &MUST-NOT; include a fragment. See
+   relative to the Effective Request URI. The URI &MUST-NOT; include a fragment. See
    <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
 </t>
@@ -2702 +2708 @@
 </t>
 <t>
-   Authors of services should not use
-   GET-based forms for the submission of sensitive data because that
-   data will be encoded in the Request-target. Many existing
-   servers, proxies, and user agents log or display the Request-target in
-   places where it might be visible to third parties. Such services can
+   Authors of services should not use GET-based forms for the submission of
+   sensitive data because that data will be encoded in the request-target. Many
+   existing servers, proxies, and user agents log or display the request-target
+   in places where it might be visible to third parties. Such services can
    use POST-based form submission instead.
 </t>
@@ -3781 +3786 @@
       "Location header payload handling"
     </t>
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
+      "Term for the requested resource's URI"
+    </t>
   </list>
 </t>

draft-ietf-httpbis/latest/p3-payload.html

@@ -401 +401 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-05-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -427 +427 @@
             </tr>
             <tr>
-               <td class="left">Expires: November 2, 2010</td>
+               <td class="left">Expires: November 27, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -484 +484 @@
             <tr>
                <td class="left"></td>
-               <td class="right">May 1, 2010</td>
+               <td class="right">May 26, 2010</td>
             </tr>
          </tbody>
@@ -510 +510 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in November 2, 2010.</p>
+      <p>This Internet-Draft will expire in November 27, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1223 +1223 @@
       </p>
       <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
-</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
-         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
+</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,
+         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
          directive is present in the message.
       </p>
@@ -1273 +1273 @@
   <a href="#header.content-location" class="smpl">Content-Location-v</a> =
                     <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
-</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
-         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.
+</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.
+         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.
       </p>
       <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.
@@ -1282 +1282 @@
          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>.
       </p>
-      <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>
+      <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>
       <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>
       <div id="rfc.iref.c.10"></div>
@@ -1450 +1450 @@
                   <td class="left">compress</td>
                   <td class="left">UNIX "compress" program method</td>
-                  <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> 
+                  <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> 
                   </td>
                </tr>
@@ -1457 +1457 @@
                   <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>)
                   </td>
-                  <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> 
+                  <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> 
                   </td>
                </tr>
@@ -1463 +1463 @@
                   <td class="left">gzip</td>
                   <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>
-                  <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> 
+                  <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> 
                   </td>
                </tr>
@@ -1730 +1730 @@
       </p>
       <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>
-      <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.
+      <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.
       </p>
       <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>
@@ -1747 +1747 @@
       </p>
       <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>
-      <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.
+      <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.
       </p>
       <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>
@@ -1792 +1792 @@
       <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
          for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are
-         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>).
+         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>).
       </p>
       <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>)
@@ -2052 +2052 @@
          </li>
          <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"
+         </li>
+      </ul>
+      <p id="rfc.section.E.11.p.2">Partly resolved issues: </p>
+      <ul>
+         <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"
          </li>
       </ul>
@@ -2192 +2197 @@
             </li>
             <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
-                  <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">
+                  <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">
                         <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a></li>
                         <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>
@@ -2199 +2204 @@
                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3.2</a></li>
                         <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">3.2.2</a></li>
-                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">A.3</a></li>
+                        <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>
+                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.27">A.3</a></li>
                         <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li>
-                        <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>
+                        <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>
                         <li class="indline1"><em>Section 6.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li>
-                        <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>
-                        <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>
+                        <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>
+                        <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>
                         <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>
                         <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>
-                        <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">A.6</a></li>
+                        <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.28">A.6</a></li>
                      </ul>
                   </li>

draft-ietf-httpbis/latest/p3-payload.xml

@@ -33 +33 @@
   <!ENTITY qvalue                   "<xref target='Part1' x:rel='#quality.values' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY uri                      "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY effective-request-uri    "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY compression-codings      "<xref target='Part1' x:rel='#compression.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY transfer-codings         "<xref target='Part1' x:rel='#transfer.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -1338 +1339 @@
 <t>
    The content-coding is a characteristic of the entity identified by
-   the request-target. Typically, the entity-body is stored with this
+   the Effective Request URI (&effective-request-uri;). Typically, the entity-body is stored with this
    encoding and is only decoded before rendering or analogous usage.
    However, a non-transparent proxy &MAY; modify the content-coding if the
@@ -1439 +1440 @@
 </artwork></figure>
 <t>
-   The Content-Location value is not a replacement for the original
-   requested URI; it is only a statement of the location of the resource
+   The Content-Location value is not a replacement for the Effective
+   Request URI (&effective-request-uri;); it is only a statement of the location of the resource
    corresponding to this particular entity at the time of the request.
-   Future requests &MAY; specify the Content-Location URI as the request-target
+   Future requests &MAY; may be addressed to the Content-Location URI
    if the desire is to identify the source of that particular
    entity.
@@ -1458 +1459 @@
 <t>
    If the Content-Location is a relative URI, the relative URI is
-   interpreted relative to the request-target.
+   interpreted relative to the Effective Request URI.
 </t>
 <t>
@@ -3150 +3151 @@
   </list>
 </t>
+<t>
+  Partly resolved issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
+      "Term for the requested resource's URI"
+    </t>
+  </list>
+</t>
 </section>
 

draft-ietf-httpbis/latest/p6-cache.html

@@ -402 +402 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-05-07">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -428 +428 @@
             </tr>
             <tr>
-               <td class="left">Expires: November 8, 2010</td>
+               <td class="left">Expires: November 27, 2010</td>
                <td class="right">J. Mogul</td>
             </tr>
@@ -489 +489 @@
             <tr>
                <td class="left"></td>
-               <td class="right">May 7, 2010</td>
+               <td class="right">May 26, 2010</td>
             </tr>
          </tbody>
@@ -515 +515 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in November 8, 2010.</p>
+      <p>This Internet-Draft will expire in November 27, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -759 +759 @@
       </p>
       <ul>
-         <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
-               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
+         <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
          </li>
          <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
@@ -860 +859 @@
          <li>HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response
             was generated. The term "date_value" denotes the value of the Date header, in a form appropriate for arithmetic operations.
-            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.
+            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.
          </li>
       </ul>
@@ -936 +935 @@
       <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.
       </p>
-      <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): 
+      <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): 
       </p>
       <ul>
@@ -943 +942 @@
          <li>POST</li>
       </ul>
-      <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
-         attacks.
+      <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.
       </p>
       <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> 
       </p>
-      <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.
-      </p>
-      <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
-         as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
+      <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>).
+      </p>
+      <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
+         mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
       </p>
       <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
@@ -967 +965 @@
       <ul>
          <li>adding or removing whitespace, where allowed in the header's syntax</li>
-         <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>)
+         <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>)
          </li>
          <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification
@@ -1253 +1251 @@
          that time.
       </p>
-      <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.
+      <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.
       </p>
       <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>
@@ -1873 +1871 @@
          </li>
       </ul>
+      <p id="rfc.section.C.11.p.2">Partly resolved issues: </p>
+      <ul>
+         <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"
+         </li>
+      </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
       <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> 
@@ -2010 +2013 @@
             </li>
             <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
-                  <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">
+                  <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">
                         <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.4</a></li>
                         <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>
                         <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>
-                        <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>
-                        <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>
-                        <li class="indline1"><em>Section 9.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">2.3.2</a></li>
+                        <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>
+                        <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>
+                        <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>
+                        <li class="indline1"><em>Section 9.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.3.2</a></li>
                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.4.2</a></li>
                      </ul>

draft-ietf-httpbis/latest/p6-cache.xml

@@ -18 +18 @@
   <!ENTITY basic-rules                 "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY uri                         "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY messaging                   "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY conditional                 "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -478 +479 @@
   For a presented request, a cache &MUST-NOT; return a stored response, unless: 
   <list style="symbols">
-    <t>The presented Request-URI and that of the stored response match
-      (<cref anchor="TODO-Request-URI">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 for this. (see <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196" />)</cref>), and</t>
+    <t>The presented Effective Request URI (&effective-request-uri;) and that of the stored response match, and</t>
     <t>the request method associated with the stored response allows it to be 
       used for the presented request, and</t>
@@ -798 +796 @@
 </t>
 <t>
-  The following HTTP methods &MUST; cause a cache to invalidate the Request-URI as well
+  The following HTTP methods &MUST; cause a cache to invalidate the Effective Request URI (&effective-request-uri;) as well
   as the URI(s) in the Location and Content-Location headers (if present):
   <list style="symbols">
@@ -808 +806 @@
 <t>
   An invalidation based on a URI from a Location or Content-Location header &MUST-NOT;
-  be performed if the host part of that URI differs from the host part in the Request-URI.
+  be performed if the host part of that URI differs from the host part in the Effective Request URI (&effective-request-uri;).
   This helps prevent denial of service attacks.
 </t>
@@ -816 +814 @@
 <t>
   A cache that passes through requests for methods it does not understand &SHOULD;
-  invalidate the Request-URI.
+  invalidate the Effective Request URI (&effective-request-uri;).
 </t>
 <t>
   Here, "invalidate" means that the cache will either remove all stored responses related
-  to the Request-URI, or will mark these as "invalid" and in need of a mandatory validation
+  to the Effective Request URI, or will mark these as "invalid" and in need of a mandatory validation
   before they can be returned in response to a subsequent request.
 </t>
@@ -2450 +2448 @@
   </list>
 </t>
+<t>
+  Partly resolved issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
+      "Term for the requested resource's URI"
+    </t>
+  </list>
+</t>
 </section>
 

draft-ietf-httpbis/latest/p7-auth.html

@@ -394 +394 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2010-05-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -425 +425 @@
             </tr>
             <tr>
-               <td class="left">Expires: November 2, 2010</td>
+               <td class="left">Expires: November 27, 2010</td>
                <td class="right">HP</td>
             </tr>
@@ -478 +478 @@
             <tr>
                <td class="left"></td>
-               <td class="right">May 1, 2010</td>
+               <td class="right">May 26, 2010</td>
             </tr>
          </tbody>
@@ -504 +504 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire in November 2, 2010.</p>
+      <p>This Internet-Draft will expire in November 27, 2010.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -657 +657 @@
       <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>
       <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
-         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.
+         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.
       </p>
       <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>
@@ -685 +685 @@
       <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>
       <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)
-         and parameters applicable to the request-target. It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
+         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.
       </p>
       <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>
@@ -938 +938 @@
       <p id="rfc.section.C.10.p.1">No significant changes.</p>
       <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>
-      <p id="rfc.section.C.11.p.1">None yet.</p>
+      <p id="rfc.section.C.11.p.1">Partly resolved issues: </p>
+      <ul>
+         <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"
+         </li>
+      </ul>
       <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
       <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> 
@@ -982 +986 @@
             </li>
             <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
-                  <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">
+                  <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">
                         <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.2</a></li>
                         <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>
+                        <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>
                      </ul>
                   </li>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -18 +18 @@
   <!ENTITY notation-abnf                "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY basic-rules                  "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY effective-request-uri      "<xref target='Part1' x:rel='#effective.request.uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY shared-and-non-shared-caches "<xref target='Part6' x:rel='#shared.and.non-shared.caches' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
 ]>
@@ -401 +402 @@
    The "Proxy-Authenticate" response-header field consists of a challenge that
    indicates the authentication scheme and parameters applicable to the proxy
-   for this request-target. It &MUST; be included as part
+   for this Effective Request URI (&effective-request-uri;). It &MUST; be included as part
    of a 407 (Proxy Authentication Required) response.
 </t>
@@ -460 +461 @@
    The "WWW-Authenticate" response-header field consists of at least one
    challenge that indicates the authentication scheme(s) and parameters
-   applicable to the request-target. It &MUST; be included in 401
+   applicable to the Effective Request URI (&effective-request-uri;). It &MUST; be included in 401
    (Unauthorized) response messages.
 </t>
@@ -977 +978 @@
 <section title="Since draft-ietf-httpbis-p7-auth-09" anchor="changes.since.09">
 <t>
-  None yet.
+  Partly resolved issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/196"/>:
+      "Term for the requested resource's URI"
+    </t>
+  </list>
 </t>
 </section>