Changeset 1163 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

Mar 10, 2011, 10:45:30 PM (9 years ago)

Author:

fielding@…

Message:

Remove header field classifications.

Addresses #224 and #104

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (22 diffs)

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

@@ -246 +246 @@
    that defines the protocol referred to as "HTTP/1.1" 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.
+   as expressed by request methods, request header fields, response status codes,
+   and response header fields.
 </t>
 </abstract>
@@ -282 +282 @@
    In particular, the sections will be ordered according to the typical
    processing of an HTTP request message (after message parsing): resource
-   mapping, general header fields, methods, request modifiers, response
-   status, and resource metadata.  The current mess reflects how widely
-   dispersed these topics and associated requirements had become in
-   <xref target="RFC2616"/>.
+   mapping, methods, request modifying header fields, response status,
+   status modifying header fields, and resource metadata.  The current mess
+   reflects how widely dispersed these topics and associated requirements
+   had become in <xref target="RFC2616"/>.
 </t>
 
@@ -530 +530 @@
   <x:anchor-alias value="request-header"/>
 <t>
-   The request-header fields allow the client to pass additional
+   The request header fields allow the client to pass additional
    information about the request, and about the client itself, to the
    server. These fields act as request modifiers, with semantics
@@ -560 +560 @@
   <c>User-Agent</c> <c><xref target="header.user-agent"/></c>
 </texttable>
-<t>
-   Request-header field names can be extended reliably only in
-   combination with a change in the protocol version. However, new or
-   experimental header fields &MAY; be given the semantics of request-header
-   fields if all parties in the communication recognize them to
-   be request-header fields.
-</t>
 </section>
 
@@ -723 +716 @@
   <x:anchor-alias value="response-header"/>
 <t>
-   The response-header fields allow the server to pass additional
+   The response header fields allow the server to pass additional
    information about the response which cannot be placed in the Status-Line.
    These header fields give information about the server and about
@@ -729 +722 @@
 </t>
 <texttable align="left">
-  <ttcol>Method Name</ttcol><ttcol>Defined in...</ttcol>
+  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>
 
   <c>Accept-Ranges</c> <c>&header-accept-ranges;</c>
@@ -742 +735 @@
   <c>WWW-Authenticate</c> <c>&header-www-authenticate;</c>
 </texttable>
-<t>
-   Response-header field names can be extended reliably only in
-   combination with a change in the protocol version. However, new or
-   experimental header fields &MAY; be given the semantics of response-header
-   fields if all parties in the communication recognize them to
-   be response-header fields.
-</t>
 </section>
 
@@ -911 +897 @@
 </t>
 <t>
-   The Max-Forwards request-header field &MAY; be used to target a
+   The Max-Forwards header field &MAY; be used to target a
    specific proxy in the request chain (see <xref target="header.max-forwards"/>).
    If no Max-Forwards field is present in the request, then the forwarded
@@ -1967 +1953 @@
   </rdf:Description>
 <t>
-   The precondition given in one or more of the request-header fields
+   The precondition given in one or more of the header fields
    evaluated to false when it was tested on the server, as defined in
    &status-412;.
@@ -2022 +2008 @@
   </rdf:Description>
 <t>
-   The request included a Range request-header field (&header-range;) and none of
+   The request included a Range header field (&header-range;) and none of
    the range-specifier values in this field overlap the current extent
    of the selected resource. See &status-416;.
@@ -2032 +2018 @@
   <iref primary="true" item="Status Codes" subitem="417 Expectation Failed" x:for-anchor=""/>
 <t>
-   The expectation given in an Expect request-header field (see <xref target="header.expect"/>)
+   The expectation given in an Expect header field (see <xref target="header.expect"/>)
    could not be met by this server, or, if the server is a proxy,
    the server has unambiguous evidence that the request could not be met
@@ -2171 +2157 @@
   <x:anchor-alias value="Allow-v"/>
 <t>
-   The "Allow" response-header field lists the set of methods advertised as
+   The "Allow" header field lists the set of methods advertised as
    supported by the target resource. The purpose of this field is strictly to
    inform the recipient of valid request methods associated with the resource.
@@ -2205 +2191 @@
   <x:anchor-alias value="expect-params"/>
 <t>
-   The "Expect" request-header field is used to indicate that particular
+   The "Expect" header field is used to indicate that particular
    server behaviors are required by the client.
 </t>
@@ -2240 +2226 @@
    return a 417 (Expectation Failed) status code if it receives a request
    with an expectation that it cannot meet. However, the Expect
-   request-header field itself is end-to-end; it &MUST; be forwarded if the
+   header field itself is end-to-end; it &MUST; be forwarded if the
    request is forwarded.
 </t>
@@ -2259 +2245 @@
   <x:anchor-alias value="mailbox"/>
 <t>
-   The "From" request-header field, if given, &SHOULD; contain an Internet
+   The "From" header field, if given, &SHOULD; contain an Internet
    e-mail address for the human user who controls the requesting user
    agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
@@ -2307 +2293 @@
   <x:anchor-alias value="Location-v"/>
 <t>
-   The "Location" response-header field is used to identify a newly created
+   The "Location" header field is used to identify a newly created
    resource, or to redirect the recipient to a different location for
    completion of the request.
@@ -2369 +2355 @@
   <x:anchor-alias value="Max-Forwards-v"/>
 <t>
-   The "Max-Forwards" request-header field provides a mechanism with the
+   The "Max-Forwards" header field provides a mechanism with the
    TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
    methods to limit the number of times that the request is forwarded by
@@ -2404 +2390 @@
   <x:anchor-alias value="Referer-v"/>
 <t>
-   The "Referer" [sic] request-header field allows the client to specify the
+   The "Referer" [sic] header field allows the client to specify the
    URI of the resource from which the effective request URI was obtained (the
    "referrer", although the header field is misspelled.).
@@ -2445 +2431 @@
   <x:anchor-alias value="Retry-After-v"/>
 <t>
-   The response-header "Retry-After" field can be used with a 503 (Service
+   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 &MAY; also be used
@@ -2485 +2471 @@
   <x:anchor-alias value="Server-v"/>
 <t>
-   The "Server" response-header field contains information about the
+   The "Server" header field contains information about the
    software used by the origin server to handle the request.
 </t>
@@ -2507 +2493 @@
 <t>
    If the response is being forwarded through a proxy, the proxy
-   application &MUST-NOT; modify the Server response-header field. Instead, it
+   application &MUST-NOT; modify the Server header field. Instead, it
    &MUST; include a Via field (as described in &header-via;).
 </t>
@@ -2527 +2513 @@
   <x:anchor-alias value="User-Agent-v"/>
 <t>
-   The "User-Agent" request-header field contains information about the user
+   The "User-Agent" header field contains information about the user
    agent originating the request. User agents &SHOULD; include this field with
    requests.