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

Timestamp:

05/07/12 17:06:19 (10 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink status code range definitions

File:

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

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

@@ -1287 +1287 @@
    HTTP does not place a pre-defined limit on the length of header fields,
    either in isolation or as a set. A server &MUST; be prepared to receive
-   request header fields of unbounded length and respond with a 4xx status
-   code if the received header field(s) would be longer than the server wishes
-   to handle.
+   request header fields of unbounded length and respond with a <x:ref>4xx
+   (Client Error)</x:ref> status code if the received header field(s) would be
+   longer than the server wishes to handle.
 </t>
 <t>
@@ -1482 +1482 @@
    Content-Length, etc.) only indicate what their values would have been
    if the request method had been GET.
-   Successful (2xx) responses to CONNECT switch to tunnel mode instead of
+   <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of
    having a message body.
-   All 1xx (Informational), <x:ref>204 (No Content)</x:ref>, and <x:ref>304
+   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and <x:ref>304
    (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
    All other responses do include a message body, although the body
@@ -1649 +1649 @@
     </t></x:lt>
     <x:lt><t>
-     Any successful (2xx) response to a CONNECT request implies that the
+     Any <x:ref>2xx (Successful)</x:ref> response to a CONNECT request implies that the
      connection will become a tunnel immediately after the empty line that
      concludes the header fields.  A client &MUST; ignore any Content-Length
@@ -2669 +2669 @@
    order sent on that connection and &MUST; associate each received response
    message to the highest ordered request that has not yet received a final
-   (non-1xx) response.
+   (non-<x:ref>1xx</x:ref>) response.
 </t>
 </section>
@@ -2761 +2761 @@
    An HTTP/1.1 server that does not support persistent connections &MUST;
    include the "close" connection option in every response message that
-   does not have a 1xx (Informational) status code.
+   does not have a <x:ref>1xx (Informational)</x:ref> status code.
 </t>
 </section>
@@ -3194 +3194 @@
         client and did not include an Expect header field with
         the "100-continue" expectation. This requirement overrides the
-        general rule for forwarding of 1xx responses (see &status-1xx;).
+        general rule for forwarding of <x:ref>1xx</x:ref> responses (see &status-1xx;).
     </t>
   </list>
@@ -3272 +3272 @@
    The Upgrade header field cannot be used to indicate a switch to a
    protocol on a different connection. For that purpose, it is more
-   appropriate to use a 3xx redirection response (&status-3xx;).
+   appropriate to use a <x:ref>3xx (Redirection)</x:ref> response (&status-3xx;).
 </t>
 <t>
@@ -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>1xx (Informational)</x:defines>
+    <x:defines>1xx</x:defines>
     <x:defines>100 (Continue)</x:defines>
     <x:defines>101 (Switching Protocols)</x:defines>
+    <x:defines>2xx (Successful)</x:defines>
+    <x:defines>2xx</x:defines>
     <x:defines>200 (OK)</x:defines>
     <x:defines>204 (No Content)</x:defines>
+    <x:defines>3xx (Redirection)</x:defines>
+    <x:defines>3xx</x:defines>
     <x:defines>301 (Moved Permanently)</x:defines>
+    <x:defines>4xx (Client Error)</x:defines>
+    <x:defines>4xx</x:defines>
     <x:defines>400 (Bad Request)</x:defines>
     <x:defines>405 (Method Not Allowed)</x:defines>