Changeset 173

Timestamp:

24/01/08 12:46:28 (14 years ago)

Author:

julian.reschke@…

Message:

Resolve #82: do not use rel_path in prose anymore, it hasn't been used inside the ABNF for http_URL since 2616 (closes #82).

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (2 diffs)
• p1-messaging.xml (modified) (2 diffs)
• p6-cache.html (modified) (2 diffs)
• p6-cache.xml (modified) (2 diffs)

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

@@ -1017 +1017 @@
          a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers
          (URI): Generic Syntax and Semantics," <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host", "abs_path",
-         "rel_path", "query", and "authority" from that specification.
+         "query", and "authority" from that specification.
       </p>
       <p id="rfc.section.3.2.1.p.2">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
@@ -2445 +2445 @@
       <ul>
          <li> &lt;<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/19</a>&gt;: "Bodies on GET (and other) requests"
+         </li>
+         <li> &lt;<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82</a>&gt;: "rel_path not used"
          </li>
       </ul>

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

@@ -1027 +1027 @@
    and <xref target="RFC1808"/>). This specification adopts the
    definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
-   "host", "abs_path", "rel_path", "query", and "authority" from that
-   specification.
+   "host", "abs_path", "query", and "authority" from that specification.
 </t>
 <t>
@@ -4167 +4166 @@
       "Bodies on GET (and other) requests"
     </t>
+    <t>
+      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82"/>:
+      "rel_path not used"
+    </t>
   </list>
 </t>

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

@@ -1146 +1146 @@
          expected to observe an origin server's explicit restrictions on caching.
       </p>
-      <p id="rfc.section.10.p.2">We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those
-         containing a "?" in the rel_path part) to perform operations with significant side effects, caches <em class="bcp14">MUST NOT</em> treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that
+      <p id="rfc.section.10.p.2">We note one exception to this rule: since some applications have traditionally used GET and HEAD requests with URLs containing
+         a query part to perform operations with significant side effects, caches <em class="bcp14">MUST NOT</em> treat responses to such URIs as fresh unless the server provides an explicit expiration time. This specifically means that
          responses from HTTP/1.0 servers for such URIs <em class="bcp14">SHOULD NOT</em> be taken from a cache. See <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for related information.
       </p>
@@ -1865 +1865 @@
       <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a>&nbsp;Since draft-ietf-httpbis-p6-cache-01
       </h2>
+      <p id="rfc.section.B.3.p.1">Closed issues: </p>
+      <ul>
+         <li> &lt;<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82</a>&gt;: "rel_path not used"
+         </li>
+      </ul>
       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
       <p>Copyright © The IETF Trust (2008).</p>

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

@@ -1375 +1375 @@
 <t>
    We note one exception to this rule: since some applications have
-   traditionally used GETs and HEADs with query URLs (those containing a
-   "?" in the rel_path part) to perform operations with significant side
+   traditionally used GET and HEAD requests with URLs containing a query part
+   to perform operations with significant side
    effects, caches &MUST-NOT; treat responses to such URIs as fresh unless
    the server provides an explicit expiration time. This specifically
@@ -2909 +2909 @@
 <section title="Since draft-ietf-httpbis-p6-cache-01">
 <t>
+  Closed issues:
+  <list style="symbols"> 
+    <t>
+      <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/82"/>:
+      "rel_path not used"
+    </t>
+  </list>
 </t>
 </section>