Changeset 1710 for draft-ietf-httpbis

Timestamp:

04/07/12 08:44:42 (10 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink status codes definitions (5xx range)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (8 diffs)
• p1-messaging.xml (modified) (5 diffs)
• p2-semantics.html (modified) (7 diffs)
• p2-semantics.xml (modified) (8 diffs)
• p6-cache.html (modified) (7 diffs)
• p6-cache.xml (modified) (3 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 4, 2013"; 
+       content: "Expires January 5, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -523 +523 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 4, 2013</td>
+               <td class="left">Expires: January 5, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 3, 2012</td>
+               <td class="right">July 4, 2012</td>
             </tr>
          </tbody>
@@ -561 +561 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 4, 2013.</p>
+      <p>This Internet-Draft will expire on January 5, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1005 +1005 @@
       </p>
       <p id="rfc.section.2.6.p.11">An HTTP server <em class="bcp14">SHOULD</em> send a response version equal to the highest version to which the server is conformant and whose major version is less than
-         or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a 505 (HTTP Version Not Supported) response if it cannot send a response using the major version used in the client's
-         request.
+         or equal to the one received in the request. An HTTP server <em class="bcp14">MUST NOT</em> send a version to which it is not conformant. A server <em class="bcp14">MAY</em> send a <a href="p2-semantics.html#status.505" class="smpl">505 (HTTP Version Not
+            Supported)</a> response if it cannot send a response using the major version used in the client's request.
       </p>
       <p id="rfc.section.2.6.p.12">An HTTP server <em class="bcp14">MAY</em> send an HTTP/1.0 response to an HTTP/1.0 request if it is known or suspected that the client incorrectly implements the HTTP
@@ -1176 +1176 @@
       </p>
       <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that
-         it implements <em class="bcp14">SHOULD</em> respond with either a 405 (Not Allowed), if it is an origin server, or a 501 (Not Implemented) status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
+         it implements <em class="bcp14">SHOULD</em> respond with either a 405 (Not Allowed), if it is an origin server, or a <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
          would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
@@ -1416 +1416 @@
          might be in the form of specific user configuration or by remembering the version of a prior received response. A server <em class="bcp14">MUST NOT</em> send a response containing Transfer-Encoding unless the corresponding request indicates HTTP/1.1 (or later).
       </p>
-      <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with 501 (Not Implemented) and then close the connection.
+      <p id="rfc.section.3.3.1.p.10">A server that receives a request message with a transfer-coding it does not understand <em class="bcp14">SHOULD</em> respond with <a href="p2-semantics.html#status.501" class="smpl">501 (Not Implemented)</a> and then close the connection.
       </p>
       <div id="rfc.iref.c.6"></div>
@@ -1477 +1477 @@
             <p>If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing
                field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and <em class="bcp14">MUST</em> be treated as an error to prevent request or response smuggling. If this is a request message, the server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code and then close the connection. If this is a response message received by a proxy,
-               the proxy <em class="bcp14">MUST</em> discard the received response, send a 502 (Bad Gateway) status code as its downstream response, and then close the connection.
-               If this is a response message received by a user-agent, it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
+               the proxy <em class="bcp14">MUST</em> discard the received response, send a <a href="p2-semantics.html#status.502" class="smpl">502 (Bad Gateway)</a> status code as its downstream response, and then close the connection. If this is a response message received by a user-agent,
+               it <em class="bcp14">MUST</em> be treated as an error by discarding the message and closing the connection.
             </p>
          </li>

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

@@ -706 +706 @@
    whose major version is less than or equal to the one received in the
    request.  An HTTP server &MUST-NOT; send a version to which it is not
-   conformant.  A server &MAY; send a 505 (HTTP
-   Version Not Supported) response if it cannot send a response using the
+   conformant.  A server &MAY; send a <x:ref>505 (HTTP Version Not
+   Supported)</x:ref> response if it cannot send a response using the
    major version used in the client's request.
 </t>
@@ -1070 +1070 @@
    A server that receives a method longer than any that it implements
    &SHOULD; respond with either a 405 (Not Allowed), if it is an origin
-   server, or a 501 (Not Implemented) status code.
+   server, or a <x:ref>501 (Not Implemented)</x:ref> status code.
    A server &MUST; be prepared to receive URIs of unbounded length and
    respond with the 414 (URI Too Long) status code if the received
@@ -1573 +1573 @@
 <t>
    A server that receives a request message with a transfer-coding it does
-   not understand &SHOULD; respond with 501 (Not Implemented) and then
+   not understand &SHOULD; respond with <x:ref>501 (Not Implemented)</x:ref> and then
    close the connection.
 </t>
@@ -1690 +1690 @@
      a 400 (Bad Request) status code and then close the connection.
      If this is a response message received by a proxy, the proxy
-     &MUST; discard the received response, send a 502 (Bad Gateway)
+     &MUST; discard the received response, send a <x:ref>502 (Bad Gateway)</x:ref>
      status code as its downstream response, and then close the connection.
      If this is a response message received by a user-agent, it &MUST; be
@@ -4108 +4108 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
-  <x:source href="p2-semantics.xml" basename="p2-semantics"/>
+  <x:source href="p2-semantics.xml" basename="p2-semantics">
+    <x:defines>501 (Not Implemented)</x:defines>
+    <x:defines>502 (Bad Gateway)</x:defines>
+    <x:defines>505 (HTTP Version Not Supported)</x:defines>
+  </x:source>
 </reference>
 

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 4, 2013"; 
+       content: "Expires January 5, 2013"; 
   } 
   @bottom-right {
@@ -497 +497 @@
       <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="2012-07-03">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
       <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, hypertext 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. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
@@ -528 +528 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 4, 2013</td>
+               <td class="left">Expires: January 5, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 3, 2012</td>
+               <td class="right">July 4, 2012</td>
             </tr>
          </tbody>
@@ -563 +563 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 4, 2013.</p>
+      <p>This Internet-Draft will expire on January 5, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -891 +891 @@
 </pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.5</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
          set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the
-         resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
-         and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
+         resource, and <a href="#status.501" class="smpl">501 (Not Implemented)</a> if the method is unrecognized or not implemented by the origin server. The methods GET and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;2.3</a>.
       </p>
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
@@ -2910 +2909 @@
          <li>If the response status code is 100 (Continue) or 101 (Switching Protocols), the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
          </li>
-         <li>If the response status code conveys a server error, e.g., 500 (Internal Server Error) or 503 (Service Unavailable), and it
-            is inconvenient or impossible to generate a valid Date.
+         <li>If the response status code conveys a server error, e.g., 500 (Internal Server Error) or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date.
          </li>
          <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field.
@@ -3039 +3037 @@
       <div id="rfc.iref.h.17"></div>
       <h2 id="rfc.section.9.16"><a href="#rfc.section.9.16">9.16</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h2>
-      <p id="rfc.section.9.16.p.1">The header "Retry-After" field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected
-         to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing
+      <p id="rfc.section.9.16.p.1">The header "Retry-After" field can be used with a <a href="#status.503" class="smpl">503 (Service
+            Unavailable)</a> response to indicate how long the service is expected to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked to wait before issuing
          the redirected request.
       </p>

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

@@ -392 +392 @@
    origin server &SHOULD; respond with the status code 405 (Method Not Allowed)
    if the method is known by the origin server but not allowed for the
-   resource, and 501 (Not Implemented) if the method is
+   resource, and <x:ref>501 (Not Implemented)</x:ref> if the method is
    unrecognized or not implemented by the origin server. The methods GET
    and HEAD &MUST; be supported by all general-purpose servers. All other
@@ -2030 +2030 @@
   <iref primary="true" item="501 Not Implemented (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="501 Not Implemented" x:for-anchor=""/>
+  <x:anchor-alias value="501 (Not Implemented)"/>
 <t>
    The server does not support the functionality required to fulfill the
@@ -2041 +2042 @@
   <iref primary="true" item="502 Bad Gateway (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="502 Bad Gateway" x:for-anchor=""/>
+  <x:anchor-alias value="502 (Bad Gateway)"/>
 <t>
    The server, while acting as a gateway or proxy, received an invalid
@@ -2051 +2053 @@
   <iref primary="true" item="503 Service Unavailable (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="503 Service Unavailable" x:for-anchor=""/>
+  <x:anchor-alias value="503 (Service Unavailable)"/>
 <t>
    The server is currently unable to handle the request due to a
@@ -2074 +2077 @@
   <iref primary="true" item="504 Gateway Timeout (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="504 Gateway Timeout" x:for-anchor=""/>
+  <x:anchor-alias value="504 (Gateway Timeout)"/>
 <t>
    The server, while acting as a gateway or proxy, did not receive a
@@ -2091 +2095 @@
   <iref primary="true" item="505 HTTP Version Not Supported (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/>
+  <x:anchor-alias value="505 (HTTP Version Not Supported)"/>
 <t>
    The server does not support, or refuses to support, the protocol
@@ -3516 +3521 @@
 
       <t>If the response status code conveys a server error, e.g., 500
-         (Internal Server Error) or 503 (Service Unavailable), and it is
-         inconvenient or impossible to generate a valid Date.</t>
+         (Internal Server Error) or <x:ref>503 (Service Unavailable)</x:ref>,
+         and it is inconvenient or impossible to generate a valid Date.</t>
 
       <t>If the server does not have a clock that can provide a
@@ -3792 +3797 @@
   <x:anchor-alias value="Retry-After"/>
 <t>
-   The header "Retry-After" field can be used with a 503 (Service
-   Unavailable) response to indicate how long the service is expected to
+   The header "Retry-After" field can be used with a <x:ref>503 (Service
+   Unavailable)</x:ref> response to indicate how long the service is expected to
    be unavailable to the requesting client. This field &MAY; also be used
    with any 3xx (Redirection) response to indicate the minimum time the

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

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires January 4, 2013"; 
+       content: "Expires January 5, 2013"; 
   } 
   @bottom-right {
@@ -494 +494 @@
       <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="2012-07-03">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
       <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, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. 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.">
@@ -520 +520 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 4, 2013</td>
+               <td class="left">Expires: January 5, 2013</td>
                <td class="right">M. Nottingham, Editor</td>
             </tr>
@@ -537 +537 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 3, 2012</td>
+               <td class="right">July 4, 2012</td>
             </tr>
          </tbody>
@@ -567 +567 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 4, 2013.</p>
+      <p>This Internet-Draft will expire on January 5, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1317 +1317 @@
       <h4 id="rfc.section.3.2.1.7"><a href="#rfc.section.3.2.1.7">3.2.1.7</a>&nbsp;<a id="cache-request-directive.only-if-cached" href="#cache-request-directive.only-if-cached">only-if-cached</a></h4>
       <p id="rfc.section.3.2.1.7.p.1">The only-if-cached request directive indicates that the client only wishes to obtain a stored response. If it receives 3ive,
-         a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504
-         (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity,
-         a member cache <em class="bcp14">MAY</em> forward such a request within that group of caches.
+         a cache <em class="bcp14">SHOULD</em> either respond using a stored response that is consistent with the other constraints of the request, or respond with a <a href="p2-semantics.html#status.504" class="smpl">504
+            (Gateway Timeout)</a> status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache <em class="bcp14">MAY</em> forward such a request within that group of caches.
       </p>
       <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="cache-response-directive" href="#cache-response-directive">Response Cache-Control Directives</a></h3>
@@ -1388 +1387 @@
       </p>
       <p id="rfc.section.3.2.2.5.p.2">The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances
-         a cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response.
+         a cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a <a href="p2-semantics.html#status.504" class="smpl">504 (Gateway Timeout)</a> response.
       </p>
       <p id="rfc.section.3.2.2.5.p.3">The must-revalidate directive ought to be used by servers if and only if failure to validate a request on the representation

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

@@ -1361 +1361 @@
    wishes to obtain a stored response. If it receives 3ive, a
    cache &SHOULD; either respond using a stored response that is consistent
-   with the other constraints of the request, or respond with a 504
-   (Gateway Timeout) status code. If a group of caches is being operated as
+   with the other constraints of the request, or respond with a <x:ref>504
+   (Gateway Timeout)</x:ref> status code. If a group of caches is being operated as
    a unified system with good internal connectivity, a member cache &MAY;
    forward such a request within that group of caches.
@@ -1504 +1504 @@
    cache &MUST; obey the must-revalidate directive; in particular,
    if a cache cannot reach the origin server for any reason, it &MUST;
-   generate a 504 (Gateway Timeout) response.
+   generate a <x:ref>504 (Gateway Timeout)</x:ref> response.
 </t>
 <t>
@@ -2287 +2287 @@
     </front>
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
-    <x:source basename="p2-semantics" href="p2-semantics.xml" />
+    <x:source basename="p2-semantics" href="p2-semantics.xml">
+      <x:defines>504 (Gateway Timeout)</x:defines>
+    </x:source>
   </reference>