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

Timestamp:

02/09/11 00:24:29 (11 years ago)

Author:

fielding@…

Message:

(editorial) rearrange some sections for better readability and
adjust some of the headings.

File:

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

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

@@ -478 +478 @@
 </section>
 
-<section title="HTTP-related architecture" anchor="architecture">
+<section title="Architecture" anchor="architecture">
 <t>
    HTTP was created for the World Wide Web architecture
@@ -1135 +1135 @@
    indicating the end of the header section, and an optional message-body.
 </t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
+  <x:ref>HTTP-message</x:ref>    = <x:ref>start-line</x:ref>
+                    *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
+                    <x:ref>CRLF</x:ref>
+                    [ <x:ref>message-body</x:ref> ]
+</artwork></figure>
+<t>
+   The normal procedure for parsing an HTTP message is to read the
+   start-line into a structure, read each header field into a hash
+   table by field name until the empty line, and then use the parsed
+   data to determine if a message-body is expected.  If a message-body
+   has been indicated, then it is read as a stream until an amount
+   of octets equal to the message-body length is read or the connection
+   is closed.
+</t>
+<t>
+   Recipients &MUST; parse an HTTP message as a sequence of octets in an
+   encoding that is a superset of US-ASCII <xref target="USASCII"/>.
+   Parsing an HTTP message as a stream of Unicode characters, without regard
+   for the specific encoding, creates security vulnerabilities due to the
+   varying ways that string processing libraries handle invalid multibyte
+   character sequences that contain the octet LF (%x0A).  String-based
+   parsers can only be safely used within protocol elements after the element
+   has been extracted from the message, such as within a header field-value
+   after message parsing has delineated the individual fields.
+</t>
+
+<section anchor="start.line" title="Start Line">
 <t>
    An HTTP message can either be a request from client to server or a
@@ -1147 +1175 @@
    and clients are implemented to only expect a response.
 </t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-message"/>
-  <x:ref>HTTP-message</x:ref>    = <x:ref>start-line</x:ref>
-                    *( <x:ref>header-field</x:ref> <x:ref>CRLF</x:ref> )
-                    <x:ref>CRLF</x:ref>
-                    [ <x:ref>message-body</x:ref> ]
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="start-line"/>
   <x:ref>start-line</x:ref>      = <x:ref>Request-Line</x:ref> / <x:ref>Status-Line</x:ref>
 </artwork></figure>
+<t>
+</t>
 <t>
    Implementations &MUST-NOT; send whitespace between the start-line and
@@ -1163 +1189 @@
    Likewise, the presence of such whitespace in a response might be
    ignored by some clients or cause others to cease parsing.
-</t>
-
-<section title="Message Parsing and Robustness" anchor="message.robustness">
-<t>
-   The normal procedure for parsing an HTTP message is to read the
-   start-line into a structure, read each header field into a hash
-   table by field name until the empty line, and then use the parsed
-   data to determine if a message-body is expected.  If a message-body
-   has been indicated, then it is read as a stream until an amount
-   of octets equal to the message-body length is read or the connection
-   is closed.
-</t>
-<t>
-   Recipients &MUST; parse an HTTP message as a sequence of octets in an
-   encoding that is a superset of US-ASCII <xref target="USASCII"/>.
-   Parsing an HTTP message as a stream of Unicode characters, without regard
-   for the specific encoding, creates security vulnerabilities due to the
-   varying ways that string processing libraries handle invalid multibyte
-   character sequences that contain the octet LF (%x0A).  String-based
-   parsers can only be safely used within protocol elements after the element
-   has been extracted from the message, such as within a header field-value
-   after message parsing has delineated the individual fields.
-</t>
-<t>
-   Older HTTP/1.0 client implementations might send an extra CRLF
-   after a POST request as a lame workaround for some early server
-   applications that failed to read message-body content that was
-   not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
-   preface or follow a request with an extra CRLF.  If terminating
-   the request message-body with a line-ending is desired, then the
-   client &MUST; include the terminating CRLF octets as part of the
-   message-body length. 
-</t>
-<t>
-   In the interest of robustness, servers &SHOULD; ignore at least one
-   empty line received where a Request-Line is expected. In other words, if
-   the server is reading the protocol stream at the beginning of a
-   message and receives a CRLF first, it &SHOULD; ignore the CRLF.
-   Likewise, although the line terminator for the start-line and header
-   fields is the sequence CRLF, we recommend that recipients recognize a
-   single LF as a line terminator and ignore any CR.
-</t>
-<t>
-   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 &MUST; respond with an HTTP/1.1 400 (Bad Request) response.  
 </t>
 </section>
@@ -1604 +1582 @@
 </section>
 
-<section anchor="incomplete.messages" title="Incomplete Messages">
+<section anchor="incomplete.messages" title="Handling Incomplete Messages">
 <t>
    Request messages that are prematurely terminated, possibly due to a
@@ -1647 +1625 @@
 </section>
 
-<section title="General Header Fields" anchor="general.header.fields">
-  <x:anchor-alias value="general-header"/>
-<t>
-   There are a few header fields which have general applicability for
-   both request and response messages, but which do not apply to the
-   payload being transferred. These header fields apply only to the
-   message being transmitted.
-</t>
-<texttable align="left">
-  <ttcol>Header Field Name</ttcol>
-  <ttcol>Defined in...</ttcol>
-  
-  <c>Connection</c> <c><xref target="header.connection"/></c>
-  <c>Date</c> <c><xref target="header.date"/></c>
-  <c>Trailer</c> <c><xref target="header.trailer"/></c>
-  <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
-  <c>Upgrade</c> <c><xref target="header.upgrade"/></c>
-  <c>Via</c> <c><xref target="header.via"/></c>
-</texttable>
+<section title="Message Parsing Robustness" anchor="message.robustness">
+<t>
+   Older HTTP/1.0 client implementations might send an extra CRLF
+   after a POST request as a lame workaround for some early server
+   applications that failed to read message-body content that was
+   not terminated by a line-ending. An HTTP/1.1 client &MUST-NOT;
+   preface or follow a request with an extra CRLF.  If terminating
+   the request message-body with a line-ending is desired, then the
+   client &MUST; include the terminating CRLF octets as part of the
+   message-body length. 
+</t>
+<t>
+   In the interest of robustness, servers &SHOULD; ignore at least one
+   empty line received where a Request-Line is expected. In other words, if
+   the server is reading the protocol stream at the beginning of a
+   message and receives a CRLF first, it &SHOULD; ignore the CRLF.
+   Likewise, although the line terminator for the start-line and header
+   fields is the sequence CRLF, we recommend that recipients recognize a
+   single LF as a line terminator and ignore any CR.
+</t>
+<t>
+   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 &MUST; respond with an HTTP/1.1 400 (Bad Request) response.  
+</t>
 </section>
 </section>
@@ -3081 +3067 @@
 <t>
    This section defines the syntax and semantics of HTTP header fields
-   related to message framing and transport protocols.
-</t>
+   related to message origination, framing, and routing.
+</t>
+<texttable align="left">
+  <ttcol>Header Field Name</ttcol>
+  <ttcol>Defined in...</ttcol>
+  
+  <c>Connection</c> <c><xref target="header.connection"/></c>
+  <c>Content-Length</c> <c><xref target="header.content-length"/></c>
+  <c>Date</c> <c><xref target="header.date"/></c>
+  <c>Host</c> <c><xref target="header.host"/></c>
+  <c>TE</c> <c><xref target="header.te"/></c>
+  <c>Trailer</c> <c><xref target="header.trailer"/></c>
+  <c>Transfer-Encoding</c> <c><xref target="header.transfer-encoding"/></c>
+  <c>Upgrade</c> <c><xref target="header.upgrade"/></c>
+  <c>Via</c> <c><xref target="header.via"/></c>
+</texttable>
 
 <section title="Connection" anchor="header.connection">