Changeset 1713 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

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

Author:

julian.reschke@…

Message:

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

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (12 diffs)

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>