Changeset 1713 for draft-ietf-httpbis

Timestamp:

04/07/12 17:59:15 (10 years ago)

Author:

julian.reschke@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (9 diffs)
• p1-messaging.xml (modified) (12 diffs)
• p2-semantics.html (modified) (10 diffs)
• p2-semantics.xml (modified) (21 diffs)
• p6-cache.html (modified) (1 diff)
• p6-cache.xml (modified) (2 diffs)
• p7-auth.html (modified) (5 diffs)
• p7-auth.xml (modified) (2 diffs)

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

@@ -1171 +1171 @@
       </p>
       <p id="rfc.section.3.1.1.p.8">Unfortunately, some user agents fail to properly encode hypertext references that have embedded whitespace, sending the characters
-         directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a 400 (Bad Request) error or a 301 (Moved Permanently) redirect with the request-target properly encoded.
-         Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
+         directly instead of properly percent-encoding the disallowed characters. Recipients of an invalid request-line <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> error or a 301 (Moved Permanently) redirect with the request-target properly encoded. Recipients <em class="bcp14">SHOULD NOT</em> attempt to autocorrect and then process the request without a redirect, since the invalid request-line might be deliberately
          crafted to bypass security filters along the request chain.
       </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 <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>).
+         it implements <em class="bcp14">SHOULD</em> respond with either a <a href="p2-semantics.html#status.405" class="smpl">405 (Method Not Allowed)</a>, 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 <a href="p2-semantics.html#status.414" class="smpl">414 (URI Too Long)</a> 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>
       <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets.
@@ -1466 +1464 @@
                the message body length is determined by reading the connection until it is closed by the server. If a Transfer-Encoding header
                field is present in a request and the "chunked" transfer-coding is not the final encoding, the message body length cannot
-               be determined reliably; the server <em class="bcp14">MUST</em> respond with the 400 (Bad Request) status code and then close the connection.
+               be determined reliably; the server <em class="bcp14">MUST</em> respond with the <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code and then close the connection.
             </p>
             <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
@@ -1476 +1474 @@
          <li>
             <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 <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,
+               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 <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> 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 <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>
@@ -1501 +1498 @@
          with HTTP/1.0.
       </p>
-      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with 411 (Length Required).
+      <p id="rfc.section.3.3.3.p.4">A server <em class="bcp14">MAY</em> reject a request that contains a message body but not a Content-Length by responding with <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a>.
       </p>
       <p id="rfc.section.3.3.3.p.5">Unless a transfer-coding other than "chunked" has been applied, a client that sends a request containing a message body <em class="bcp14">SHOULD</em> use a valid Content-Length header field if the message body length is known in advance, rather than the "chunked" encoding,
-         since some existing services respond to "chunked" with a 411 (Length Required) status code even though they understand the
-         chunked encoding. This is typically because such services are implemented via a gateway that requires a content-length in
-         advance of being called and the server is unable or unwilling to buffer the entire request before processing.
+         since some existing services respond to "chunked" with a <a href="p2-semantics.html#status.411" class="smpl">411 (Length Required)</a> status code even though they understand the chunked encoding. This is typically because such services are implemented via
+         a gateway that requires a content-length in advance of being called and the server is unable or unwilling to buffer the entire
+         request before processing.
       </p>
       <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid Content-Length header field if it does not know the server will handle HTTP/1.1 (or later) requests; such
@@ -1542 +1539 @@
       <p id="rfc.section.3.5.p.3">When a server listening only for HTTP request messages, or processing what appears from the start-line to be an HTTP request
          message, receives a sequence of octets that does not match the HTTP-message grammar aside from the robustness exceptions listed
-         above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 400 (Bad Request) response.
+         above, the server <em class="bcp14">MUST</em> respond with an HTTP/1.1 <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> response.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="transfer.codings" href="#transfer.codings">Transfer Codings</a></h1>
@@ -1856 +1853 @@
          without first verifying that the intercepted connection is targeting a valid IP address for that host.
       </p>
-      <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message that lacks a Host header field and to any request
-         message that contains more than one Host header field or a Host header field with an invalid field-value.
+      <p id="rfc.section.5.4.p.9">A server <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.400" class="smpl">400 (Bad Request)</a> status code to any HTTP/1.1 request message that lacks a Host header field and to any request message that contains more than
+         one Host header field or a Host header field with an invalid field-value.
       </p>
       <div id="rfc.iref.e.1"></div>
@@ -2182 +2179 @@
       </ul>
       <p id="rfc.section.6.4.3.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
-         100-continue" without receiving either a 417 (Expectation Failed) or a 100 (Continue) status code. Therefore, when a client
-         sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status code,
-         the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
+         100-continue" without receiving either a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> or a 100 (Continue) status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy)
+         from which it has never seen a 100 (Continue) status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
       </p>
       <p id="rfc.section.6.4.3.p.4">Requirements for HTTP/1.1 origin servers: </p>
@@ -2216 +2212 @@
             it <em class="bcp14">MUST</em> forward the request, including the Expect header field.
          </li>
-         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code.
+         <li>If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it <em class="bcp14">MUST NOT</em> forward the request, and it <em class="bcp14">MUST</em> respond with a <a href="p2-semantics.html#status.417" class="smpl">417 (Expectation Failed)</a> status code.
          </li>
          <li>Proxies <em class="bcp14">SHOULD</em> maintain a record of the HTTP version numbers received from recently-referenced next-hop servers.
@@ -2262 +2258 @@
       </p>
       <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
-         to, and <em class="bcp14">MUST</em> include it in 426 (Upgrade Required) responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
+         to, and <em class="bcp14">MUST</em> include it in <a href="p2-semantics.html#status.426" class="smpl">426 (Upgrade Required)</a> responses to indicate acceptable protocols to upgrade to. Servers <em class="bcp14">MAY</em> include it in any other response to indicate that they are willing to upgrade to one of the specified protocols.
       </p>
       <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined

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

@@ -1060 +1060 @@
    directly instead of properly percent-encoding the disallowed characters.
    Recipients of an invalid request-line &SHOULD; respond with either a
-   400 (Bad Request) error or a 301 (Moved Permanently) redirect with the
+   <x:ref>400 (Bad Request)</x:ref> error or a 301 (Moved Permanently) redirect with the
    request-target properly encoded.  Recipients &SHOULD-NOT; attempt to
    autocorrect and then process the request without a redirect, since the
@@ -1069 +1069 @@
    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
-   &SHOULD; respond with either a 405 (Not Allowed), if it is an origin
+   &SHOULD; respond with either a <x:ref>405 (Method Not Allowed)</x:ref>, if it is an origin
    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
+   respond with the <x:ref>414 (URI Too Long)</x:ref> status code if the received
    request-target would be longer than the server wishes to handle
    (see &status-414;).
@@ -1669 +1669 @@
      "chunked" transfer-coding is not the final encoding, the message body
      length cannot be determined reliably; the server &MUST; respond with
-     the 400 (Bad Request) status code and then close the connection.
+     the <x:ref>400 (Bad Request)</x:ref> status code and then close the connection.
     </t>
     <t>
@@ -1688 +1688 @@
      prevent request or response smuggling.
      If this is a request message, the server &MUST; respond with
-     a 400 (Bad Request) status code and then close the connection.
+     a <x:ref>400 (Bad Request)</x:ref> 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 <x:ref>502 (Bad Gateway)</x:ref>
@@ -1730 +1730 @@
 <t>
    A server &MAY; reject a request that contains a message body but
-   not a Content-Length by responding with 411 (Length Required).
+   not a Content-Length by responding with <x:ref>411 (Length Required)</x:ref>.
 </t>
 <t>
@@ -1737 +1737 @@
    use a valid Content-Length header field if the message body length
    is known in advance, rather than the "chunked" encoding, since some
-   existing services respond to "chunked" with a 411 (Length Required)
+   existing services respond to "chunked" with a <x:ref>411 (Length Required)</x:ref>
    status code even though they understand the chunked encoding.  This
    is typically because such services are implemented via a gateway that
@@ -1821 +1821 @@
    receives a sequence of octets that does not match the HTTP-message
    grammar aside from the robustness exceptions listed above, the
-   server &MUST; respond with an HTTP/1.1 400 (Bad Request) response.  
+   server &MUST; respond with an HTTP/1.1 <x:ref>400 (Bad Request)</x:ref> response.  
 </t>
 </section>
@@ -2410 +2410 @@
 </t>
 <t>
-   A server &MUST; respond with a 400 (Bad Request) status code to
-   any HTTP/1.1 request message that lacks a Host header field and
+   A server &MUST; respond with a <x:ref>400 (Bad Request)</x:ref> status code
+   to any HTTP/1.1 request message that lacks a Host header field and
    to any request message that contains more than one Host header field
    or a Host header field with an invalid field-value.
@@ -3117 +3117 @@
    Because of the presence of older implementations, the protocol allows
    ambiguous situations in which a client might send "Expect: 100-continue"
-   without receiving either a 417 (Expectation Failed) 
+   without receiving either a <x:ref>417 (Expectation Failed)</x:ref> 
    or a 100 (Continue) status code. Therefore, when a client sends this
    header field to an origin server (possibly via a proxy) from which it
@@ -3185 +3185 @@
     <t> If the proxy knows that the version of the next-hop server is
         HTTP/1.0 or lower, it &MUST-NOT; forward the request, and it &MUST;
-        respond with a 417 (Expectation Failed) status code.
+        respond with a <x:ref>417 (Expectation Failed)</x:ref> status code.
     </t>
     <t> Proxies &SHOULD; maintain a record of the HTTP version
@@ -3277 +3277 @@
    Servers &MUST; include the "Upgrade" header field in 101 (Switching
    Protocols) responses to indicate which protocol(s) are being switched to,
-   and &MUST; include it in 426 (Upgrade Required) responses to indicate
+   and &MUST; include it in <x:ref>426 (Upgrade Required)</x:ref> responses to indicate
    acceptable protocols to upgrade to. Servers &MAY; include it in any other
    response to indicate that they are willing to upgrade to one of the
@@ -4109 +4109 @@
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
   <x:source href="p2-semantics.xml" basename="p2-semantics">
+    <x:defines>400 (Bad Request)</x:defines>
+    <x:defines>405 (Method Not Allowed)</x:defines>
+    <x:defines>411 (Length Required)</x:defines>
+    <x:defines>414 (URI Too Long)</x:defines>
+    <x:defines>417 (Expectation Failed)</x:defines>
+    <x:defines>426 (Upgrade Required)</x:defines>
     <x:defines>501 (Not Implemented)</x:defines>
     <x:defines>502 (Bad Gateway)</x:defines>

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

@@ -891 +891 @@
       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#methods" class="smpl">method</a>         = <a href="#core.rules" class="smpl">token</a>
 </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 <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>.
+         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> if the method is known by the origin server but not allowed for the 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>
@@ -1054 +1053 @@
          related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
          with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an
-         appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict)
-         or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type
-         values.
+         appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on Content-Type values.
       </p>
       <p id="rfc.section.2.3.5.p.5">For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being
@@ -1920 +1917 @@
       </p>
       <p id="rfc.section.4.6.3.p.2">If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it <em class="bcp14">SHOULD</em> describe the reason for the refusal in the representation. If the server does not wish to make this information available
-         to the client, the status code 404 (Not Found) <em class="bcp14">MAY</em> be used instead.
+         to the client, the status code <a href="#status.404" class="smpl">404
+            (Not Found)</a>  <em class="bcp14">MAY</em> be used instead.
       </p>
       <div id="rfc.iref.39"></div>
@@ -1926 +1924 @@
       <h3 id="rfc.section.4.6.4"><a href="#rfc.section.4.6.4">4.6.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
       <p id="rfc.section.4.6.4.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
+         or permanent. The <a href="#status.410" class="smpl">410 (Gone)</a> 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
          has been refused, or when no other response is applicable.
@@ -1976 +1974 @@
       <p id="rfc.section.4.6.9.p.1">The target 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 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.
+         whether or not the condition is permanent, the status code <a href="#status.404" class="smpl">404 (Not Found)</a>  <em class="bcp14">SHOULD</em> be used instead.
       </p>
       <p id="rfc.section.4.6.9.p.2">The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource
@@ -2536 +2534 @@
       <p id="rfc.section.8.1.p.4">Server-driven negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor
          them. For example, the origin server might not implement server-driven negotiation, or it might decide that sending a response
-         that doesn't conform to them is better than sending a 406 (Not Acceptable) response.
+         that doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
+            (Not Acceptable)</a> response.
       </p>
       <p id="rfc.section.8.1.p.5">Many of the mechanisms for expressing preferences use quality values to declare relative preference. See <a href="p1-messaging.html#quality.values" title="Quality Values">Section 4.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.47"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for more information.
@@ -2566 +2565 @@
          and used within HTTP/1.1.
       </p>
-      <p id="rfc.section.8.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
-         when the server is unwilling or unable to provide a varying response using server-driven negotiation.
+      <p id="rfc.section.8.2.p.4">This specification defines the 300 (Multiple Choices) and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using
+         server-driven negotiation.
       </p>
       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
@@ -2609 +2608 @@
       <p id="rfc.section.9.1.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept
          header field is present in a request and none of the available representations for the response have a media type that is
-         listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a 406 (Not Acceptable) response or disregard the Accept header field by treating
-         the response as if it is not subject to content negotiation.
+         listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Accept header field by treating the response as if it is not subject to content negotiation.
       </p>
       <p id="rfc.section.9.1.p.10">A more elaborate example is</p>
@@ -2693 +2691 @@
       <p id="rfc.section.9.2.p.6">A request without any Accept-Charset header field implies that the user agent will accept any character encoding in response.
          If an Accept-Charset header field is present in a request and none of the available representations for the response have
-         a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a 406 (Not Acceptable) response or disregard the Accept-Charset header
-         field by treating the response as if it is not subject to content negotiation.
+         a character encoding that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Accept-Charset header field by treating the response as if it is not subject to content negotiation.
       </p>
       <div id="rfc.iref.a.3"></div>
@@ -2938 +2935 @@
   <a href="#header.expect" class="smpl">expect-value</a> = <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a>
 </pre><p id="rfc.section.9.11.p.3">If all received Expect header field(s) are syntactically valid but contain an expectation that the recipient does not understand
-         or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417.
+         or cannot comply with, the recipient <em class="bcp14">MUST</em> respond with a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> status code. A recipient of a syntactically invalid Expectation header field <em class="bcp14">MUST</em> respond with a 4xx status code other than 417.
       </p>
       <p id="rfc.section.9.11.p.4">The only expectation defined by this specification is:</p>

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

@@ -391 +391 @@
    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 &SHOULD; respond with the status code 405 (Method Not Allowed)
+   origin server &SHOULD; respond with the status code <x:ref>405 (Method Not Allowed)</x:ref>
    if the method is known by the origin server but not allowed for the
    resource, and <x:ref>501 (Not Implemented)</x:ref> if the method is
@@ -731 +731 @@
    representation or changing the resource configuration, or respond
    with an appropriate error message containing sufficient information
-   to explain why the representation is unsuitable.  The 409 (Conflict)
-   or 415 (Unsupported Media Type) status codes are suggested, with the
+   to explain why the representation is unsuitable.  The <x:ref>409 (Conflict)</x:ref>
+   or <x:ref>415 (Unsupported Media Type)</x:ref> status codes are suggested, with the
    latter being specific to constraints on Content-Type values.
 </t>
@@ -1764 +1764 @@
   <iref primary="true" item="400 Bad Request (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="400 Bad Request" x:for-anchor=""/>
+  <x:anchor-alias value="400 (Bad Request)"/>
 <t>
    The server cannot or will not process the request, due to a client error (e.g.,
@@ -1781 +1782 @@
   <iref primary="true" item="403 Forbidden (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="403 Forbidden" x:for-anchor=""/>
+  <x:anchor-alias value="403 (Forbidden)"/>
 <t>
    The server understood the request, but refuses to authorize it. Providing
@@ -1791 +1793 @@
    public why the request has not been fulfilled, it &SHOULD; describe the
    reason for the refusal in the representation.  If the server does not wish to
-   make this information available to the client, the status code 404
-   (Not Found) &MAY; be used instead.
+   make this information available to the client, the status code <x:ref>404
+   (Not Found)</x:ref> &MAY; be used instead.
 </t>
 </section>
@@ -1799 +1801 @@
   <iref primary="true" item="404 Not Found (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="404 Not Found" x:for-anchor=""/>
+  <x:anchor-alias value="404 (Not Found)"/>
 <t>
    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
+   permanent. The <x:ref>410 (Gone)</x:ref> status code &SHOULD; be used if the server
    knows, through some internally configurable mechanism, that an old
    resource is permanently unavailable and has no forwarding address.
@@ -1814 +1817 @@
   <iref primary="true" item="405 Method Not Allowed (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="405 Method Not Allowed" x:for-anchor=""/>
+  <x:anchor-alias value="405 (Method Not Allowed)"/>
 <t>
    The method specified in the request-line is not allowed for the target
@@ -1824 +1828 @@
   <iref primary="true" item="406 Not Acceptable (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="406 Not Acceptable" x:for-anchor=""/>
+  <x:anchor-alias value="406 (Not Acceptable)"/>
 <t>
    The resource identified by the request is only capable of generating
@@ -1867 +1872 @@
   <iref primary="true" item="409 Conflict (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="409 Conflict" x:for-anchor=""/>
+  <x:anchor-alias value="409 (Conflict)"/>
 <t>
    The request could not be completed due to a conflict with the current
@@ -1891 +1897 @@
   <iref primary="true" item="410 Gone (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="410 Gone" x:for-anchor=""/>
+  <x:anchor-alias value="410 (Gone)"/>
 <t>
    The target resource is no longer available at the server and no
@@ -1897 +1904 @@
    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
-   used instead.
+   the condition is permanent, the status code <x:ref>404 (Not Found)</x:ref>
+   &SHOULD; be used instead.
 </t>
 <t>
@@ -1920 +1927 @@
   <iref primary="true" item="411 Length Required (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="411 Length Required" x:for-anchor=""/>
+  <x:anchor-alias value="411 (Length Required)"/>
 <t>
    The server refuses to accept the request without a defined Content-Length.
@@ -1947 +1955 @@
   <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
+  <x:anchor-alias value="414 (URI Too Long)"/>
 <t>
    The server is refusing to service the request because the effective request URI
@@ -1963 +1972 @@
   <iref primary="true" item="415 Unsupported Media Type (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="415 Unsupported Media Type" x:for-anchor=""/>
+  <x:anchor-alias value="415 (Unsupported Media Type)"/>
 <t>
    The server is refusing to service the request because the request
@@ -1973 +1983 @@
   <iref primary="true" item="417 Expectation Failed (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/>
+  <x:anchor-alias value="417 (Expectation Failed)"/>
 <t>
    The expectation given in an Expect header field (see <xref target="header.expect"/>)
@@ -1984 +1995 @@
   <iref primary="true" item="426 Upgrade Required (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="426 Upgrade Required" x:for-anchor=""/>
+  <x:anchor-alias value="426 (Upgrade Required)"/>
 <t>
    The request can not be completed without a prior protocol upgrade. This
@@ -2853 +2865 @@
    but it cannot expect responses to always honor them. For example, the origin
    server might not implement server-driven negotiation, or it might decide that
-   sending a response that doesn't conform to them is better than sending a 406
-   (Not Acceptable) response.
+   sending a response that doesn't conform to them is better than sending a <x:ref>406
+   (Not Acceptable)</x:ref> response.
 </t>
 <t>
@@ -2913 +2925 @@
 </t>
 <t>
-   This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable)
+   This specification defines the 300 (Multiple Choices) and <x:ref>406 (Not Acceptable)</x:ref>
    status codes for enabling agent-driven negotiation when the server is
    unwilling or unable to provide a varying response using server-driven
@@ -2993 +3005 @@
    If an Accept header field is present in a request and none of the
    available representations for the response have a media type that is
-   listed as acceptable, the origin server &MAY; either
-   honor the Accept header field by sending a 406 (Not Acceptable) response
+   listed as acceptable, the origin server &MAY; either honor the Accept
+   header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response
    or disregard the Accept header field by treating the response as if
    it is not subject to content negotiation.
@@ -3094 +3106 @@
    available representations for the response have a character encoding that
    is listed as acceptable, the origin server &MAY; either honor the
-   Accept-Charset header field by sending a 406 (Not Acceptable) response or
+   Accept-Charset header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response or
    disregard the Accept-Charset header field by treating the response as if
    it is not subject to content negotiation.
@@ -3578 +3590 @@
    If all received Expect header field(s) are syntactically valid but contain
    an expectation that the recipient does not understand or cannot comply with,
-   the recipient &MUST; respond with a 417 (Expectation Failed) status code. A
+   the recipient &MUST; respond with a <x:ref>417 (Expectation Failed)</x:ref> status code. A
    recipient of a syntactically invalid Expectation header field &MUST; respond
    with a 4xx status code other than 417.

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

@@ -833 +833 @@
       <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common
          form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of
-         the resource identified by the request target. However, it is also possible to cache negative results (e.g., 404 not found),
-         incomplete results (e.g., 206 partial content), and responses to safe methods other than GET if the method's definition allows
-         such caching and defines something suitable for use as a cache key.
+         the resource identified by the request target. However, it is also possible to cache negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable
+         for use as a cache key.
       </p>
       <p id="rfc.section.2.p.3">The default <dfn>cache key</dfn> consists of the request method and target URI. However, since HTTP caches in common use today are typically limited to caching

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

@@ -434 +434 @@
    request: i.e., a 200 (OK) response containing a representation of the
    resource identified by the request target.  However, it is also possible
-   to cache negative results (e.g., 404 not found), incomplete results
-   (e.g., 206 partial content), and responses to safe methods other than
+   to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results
+   (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than
    GET if the method's definition allows such caching and defines something
    suitable for use as a cache key.
@@ -2288 +2288 @@
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
     <x:source basename="p2-semantics" href="p2-semantics.xml">
+      <x:defines>404 (Not Found)</x:defines>
       <x:defines>504 (Gateway Timeout)</x:defines>
     </x:source>

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 4, 2013"; 
+       content: "Expires January 5, 2013"; 
   } 
   @bottom-right {
@@ -489 +489 @@
       <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="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, 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 the HTTP Authentication framework.">
@@ -520 +520 @@
             </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>
@@ -553 +553 @@
          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>
@@ -715 +715 @@
          a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy.
       </p>
-      <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden)
-         status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+      <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 4.6.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.2.1.p.17">The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional

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

@@ -329 +329 @@
 <t>
    A server receiving credentials that are valid, but not adequate to gain
-   access, ought to respond with the 403 (Forbidden) status code (&status.403;).
+   access, ought to respond with the <x:ref>403 (Forbidden)</x:ref> status code (&status.403;).
 </t>
 <t>
@@ -892 +892 @@
   </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>403 (Forbidden)</x:defines>
+  </x:source>
 </reference>