Changeset 1163 for draft-ietf-httpbis/latest

Timestamp:

11/03/11 06:45:30 (11 years ago)

Author:

fielding@…

Message:

Remove header field classifications.

Addresses #224 and #104

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.xml (modified) (31 diffs)
• p2-semantics.xml (modified) (22 diffs)
• p3-payload.xml (modified) (9 diffs)
• p4-conditional.xml (modified) (8 diffs)
• p5-range.xml (modified) (7 diffs)
• p6-cache.xml (modified) (14 diffs)
• p7-auth.xml (modified) (6 diffs)

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

@@ -31 +31 @@
   <!ENTITY header-warning         "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY idempotent-methods     "<xref target='Part2' x:rel='#idempotent.methods' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY request-header-fields  "<xref target='Part2' x:rel='#request.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
-  <!ENTITY response-header-fields "<xref target='Part2' x:rel='#response.header.fields' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-codes           "<xref target='Part2' x:rel='#status.codes' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-100             "<xref target='Part2' x:rel='#status.100' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -517 +515 @@
 </section>
 
-<section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
-  <x:anchor-alias value="request-header"/>
-  <x:anchor-alias value="response-header"/>
-  <x:anchor-alias value="Cache-Control"/>
-  <x:anchor-alias value="Pragma"/>
-  <x:anchor-alias value="Warning"/>
-  <x:anchor-alias value="MIME-Version"/>
-<t>
-  The ABNF rules below are defined in other parts: 
-</t>
-<figure><!-- Part2--><artwork type="abnf2616">
-  <x:ref>request-header</x:ref>  = &lt;request-header, defined in &request-header-fields;&gt;
-  <x:ref>response-header</x:ref> = &lt;response-header, defined in &response-header-fields;&gt;
-</artwork></figure>
-<figure><!-- Part3--><artwork type="abnf2616">
-  <x:ref>MIME-Version</x:ref>    = &lt;MIME-Version, defined in &header-mime-version;&gt;
-</artwork></figure>
-<figure><!-- Part6--><artwork type="abnf2616">
-  <x:ref>Cache-Control</x:ref>   = &lt;Cache-Control, defined in &header-pragma;&gt;
-  <x:ref>Pragma</x:ref>          = &lt;Pragma, defined in &header-pragma;&gt;
-  <x:ref>Warning</x:ref>         = &lt;Warning, defined in &header-warning;&gt;
-</artwork></figure>
-</section>
-
 </section>
 </section>
@@ -1095 +1069 @@
    are never "public" and thus are ineligible for shared caching.
    Their default is "private" and might be further constrained via use
-   of the Cache-Control header field.
+   of the Cache-Control header field (&header-cache-control;).
 </t>
 <t>
@@ -1556 +1530 @@
   <c>Connection</c> <c><xref target="header.connection"/></c>
   <c>Date</c> <c><xref target="header.date"/></c>
-  <c>Pragma</c> <c>&header-pragma;</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>
-  <c>Warning</c> <c>&header-warning;</c>
-  <c>MIME-Version</c> <c>&header-mime-version;</c>
 </texttable>
-<t>
-   General-header field names can be extended reliably only in
-   combination with a change in the protocol version. However, new or
-   experimental header fields might be given the semantics of general
-   header fields if all parties in the communication recognize them to
-   be general-header fields.
-</t>
 </section>
 </section>
@@ -2773 +2737 @@
     <t>
         If a client will wait for a 100 (Continue) response before
-        sending the request body, it &MUST; send an Expect request-header
+        sending the request body, it &MUST; send an Expect header
         field (&header-expect;) with the "100-continue" expectation.
     </t>
     <t>
-        A client &MUST-NOT; send an Expect request-header field (&header-expect;)
+        A client &MUST-NOT; send an Expect header field (&header-expect;)
         with the "100-continue" expectation if it does not intend
         to send a request body.
@@ -2795 +2759 @@
    Requirements for HTTP/1.1 origin servers:
   <list style="symbols">
-    <t> Upon receiving a request which includes an Expect request-header
+    <t> Upon receiving a request which includes an Expect header
         field with the "100-continue" expectation, an origin server &MUST;
         either respond with 100 (Continue) status code and continue to read
@@ -2806 +2770 @@
     </t>
     <t> An origin server &SHOULD-NOT;  send a 100 (Continue) response if
-        the request message does not include an Expect request-header
+        the request message does not include an Expect header
         field with the "100-continue" expectation, and &MUST-NOT; send a
         100 (Continue) response if such a request comes from an HTTP/1.0
@@ -2812 +2776 @@
         compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue)
         status code in response to an HTTP/1.1 PUT or POST request that does
-        not include an Expect request-header field with the "100-continue"
+        not include an Expect header field with the "100-continue"
         expectation. This exception, the purpose of which is
         to minimize any client processing delays associated with an
@@ -2829 +2793 @@
     </t>
     <t> If an origin server receives a request that does not include an
-        Expect request-header field with the "100-continue" expectation,
+        Expect header field with the "100-continue" expectation,
         the request includes a request body, and the server responds
         with a final status code before reading the entire request body
@@ -2845 +2809 @@
    Requirements for HTTP/1.1 proxies:
   <list style="symbols">
-    <t> If a proxy receives a request that includes an Expect request-header
+    <t> If a proxy receives a request that includes an Expect header
         field with the "100-continue" expectation, and the proxy
         either knows that the next-hop server complies with HTTP/1.1 or
@@ -2861 +2825 @@
     <t> A proxy &MUST-NOT; forward a 100 (Continue) response if the
         request message was received from an HTTP/1.0 (or earlier)
-        client and did not include an Expect request-header field with
+        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;).
@@ -2872 +2836 @@
 <t>
    If an HTTP/1.1 client sends a request which includes a request body,
-   but which does not include an Expect request-header field with the
+   but which does not include an Expect header field with the
    "100-continue" expectation, and if the client is not directly
    connected to an HTTP/1.1 origin server, and if the client sees the
@@ -2884 +2848 @@
     </t>
     <t>
-      Transmit the request-header fields
+      Transmit the request-line, header fields, and the CRLF that
+      indicates the end of header fields.
     </t>
     <t>
@@ -2972 +2937 @@
   <x:anchor-alias value="Connection-v"/>
 <t>
-   The "Connection" general-header field allows the sender to specify
+   The "Connection" header field allows the sender to specify
    options that are desired for that particular connection and &MUST-NOT;
    be communicated by proxies over further connections.
@@ -2996 +2961 @@
 <t>
    Message header fields listed in the Connection header field &MUST-NOT; include
-   end-to-end header fields, such as Cache-Control.
+   end-to-end header fields, such as Cache-Control (&header-cache-control;).
 </t>
 <t>
@@ -3079 +3044 @@
   <x:anchor-alias value="Date-v"/>
 <t>
-   The "Date" general-header field represents the date and time at which
+   The "Date" header field represents the date and time at which
    the message was originated, having the same semantics as the Origination
    Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
@@ -3155 +3120 @@
   <x:anchor-alias value="Host-v"/>
 <t>
-   The "Host" request-header field specifies the Internet host and port
+   The "Host" header field specifies the Internet host and port
    number of the resource being requested, allowing the origin server or
    gateway to differentiate between internally-ambiguous URLs, such as the root
@@ -3207 +3172 @@
   <x:anchor-alias value="te-ext"/>
 <t>
-   The "TE" request-header field indicates what extension transfer-codings
+   The "TE" header field indicates what extension transfer-codings
    it is willing to accept in the response, and whether or not it is
    willing to accept trailer fields in a chunked transfer-coding.
@@ -3288 +3253 @@
   <x:anchor-alias value="Trailer-v"/>
 <t>
-   The "Trailer" general-header field indicates that the given set of
+   The "Trailer" header field indicates that the given set of
    header fields is present in the trailer of a message encoded with
    chunked transfer-coding.
@@ -3324 +3289 @@
   <x:anchor-alias value="Transfer-Encoding-v"/>
 <t>
-   The "Transfer-Encoding" general-header field indicates what transfer-codings
+   The "Transfer-Encoding" header field indicates what transfer-codings
    (if any) have been applied to the message body. It differs from 
    Content-Encoding (&content-codings;) in that transfer-codings are a property
@@ -3359 +3324 @@
   <x:anchor-alias value="Upgrade-v"/>
 <t>
-   The "Upgrade" general-header field allows the client to specify what
+   The "Upgrade" header field allows the client to specify what
    additional communication protocols it would like to use, if the server 
    chooses to switch protocols. Servers can use it to indicate what protocols
@@ -3471 +3436 @@
   <x:anchor-alias value="Via-v"/>
 <t>
-   The "Via" general-header field &MUST; be used by gateways and proxies to
+   The "Via" header field &MUST; be used by gateways and proxies to
    indicate the intermediate protocols and recipients between the user
    agent and the server on requests, and between the origin server and
@@ -4922 +4887 @@
 <section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
 <t>
-   The requirements that clients and servers support the Host request-header
+   The requirements that clients and servers support the Host header
    field (<xref target="header.host"/>), report an error if it is
    missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
@@ -4945 +4910 @@
    requirements:
   <list style="symbols">
-     <t>Both clients and servers &MUST; support the Host request-header field.</t>
+     <t>Both clients and servers &MUST; support the Host header field.</t>
 
      <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t>
 
      <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1
-        request does not include a Host request-header field.</t>
+        request does not include a Host header field.</t>
 
      <t>Servers &MUST; accept absolute URIs.</t>
@@ -5054 +5019 @@
 <x:ref>BWS</x:ref> = OWS
 
-<x:ref>Cache-Control</x:ref> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
 <x:ref>Chunked-Body</x:ref> = *chunk last-chunk trailer-part CRLF
 <x:ref>Connection</x:ref> = "Connection:" OWS Connection-v
@@ -5075 +5039 @@
 <x:ref>Host-v</x:ref> = uri-host [ ":" port ]
 
-<x:ref>MIME-Version</x:ref> = &lt;MIME-Version, defined in [Part3], Appendix A.1&gt;
 <x:ref>Method</x:ref> = token
 
 <x:ref>OWS</x:ref> = *( [ obs-fold ] WSP )
-
-<x:ref>Pragma</x:ref> = &lt;Pragma, defined in [Part6], Section 3.4&gt;
 
 <x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP )
@@ -5107 +5068 @@
  ] *( OWS "," [ OWS received-protocol RWS received-by [ RWS comment ]
  ] )
-
-<x:ref>Warning</x:ref> = &lt;Warning, defined in [Part6], Section 3.6&gt;
 
 <x:ref>absolute-URI</x:ref> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;
@@ -5203 +5162 @@
 <x:ref>received-protocol</x:ref> = [ protocol-name "/" ] protocol-version
 <x:ref>relative-part</x:ref> = &lt;relative-part, defined in [RFC3986], Section 4.2&gt;
-<x:ref>request-header</x:ref> = &lt;request-header, defined in [Part2], Section 3&gt;
 <x:ref>request-target</x:ref> = "*" / absolute-URI / ( path-absolute [ "?" query ] )
  / authority
-<x:ref>response-header</x:ref> = &lt;response-header, defined in [Part2], Section 5&gt;
 <x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT
 <x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT
@@ -5238 +5195 @@
 </figure>
 <figure><preamble>ABNF diagnostics:</preamble><artwork type="inline">
-; Cache-Control defined but not used
 ; Chunked-Body defined but not used
 ; Connection defined but not used
@@ -5245 +5201 @@
 ; HTTP-message defined but not used
 ; Host defined but not used
-; MIME-Version defined but not used
-; Pragma defined but not used
 ; Request defined but not used
 ; Response defined but not used
@@ -5255 +5209 @@
 ; Upgrade defined but not used
 ; Via defined but not used
-; Warning defined but not used
 ; http-URI defined but not used
 ; https-URI defined but not used
 ; partial-URI defined but not used
-; request-header defined but not used
-; response-header defined but not used
 ; special defined but not used
 </artwork></figure></section>

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.

draft-ietf-httpbis/latest/p3-payload.xml

@@ -908 +908 @@
 </t>
 <t>
-   HTTP/1.1 includes the following request-header fields for enabling
+   HTTP/1.1 includes the following header fields for enabling
    server-driven negotiation through description of user agent
    capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
@@ -914 +914 @@
    (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;).
    However, an origin server is not limited to these dimensions and &MAY; vary 
-   the response based on any aspect of the request, including information
-   outside the request-header fields or within extension header fields
-   not defined by this specification.
+   the response based on any aspect of the request, including aspects
+   of the connection (e.g., IP address) or information within extension
+   header fields not defined by this specification.
 </t>
 <x:note>
@@ -983 +983 @@
   <x:anchor-alias value="media-range"/>
 <t>
-   The "Accept" request-header field can be used by user agents to specify
+   The "Accept" header field can be used by user agents to specify
    response media types that are acceptable. Accept header fields can be used to
    indicate that the request is specifically limited to a small set of desired
@@ -1108 +1108 @@
   <x:anchor-alias value="Accept-Charset-v"/>
 <t>
-   The "Accept-Charset" request-header field can be used by user agents to
+   The "Accept-Charset" header field can be used by user agents to
    indicate what response character sets are acceptable. This field allows
    clients capable of understanding more comprehensive or special-purpose
@@ -1153 +1153 @@
   <x:anchor-alias value="codings"/>
 <t>
-   The "Accept-Encoding" request-header field can be used by user agents to
+   The "Accept-Encoding" header field can be used by user agents to
    indicate what response content-codings (<xref target="content.codings"/>)
    are acceptable in the response.
@@ -1243 +1243 @@
   <x:anchor-alias value="language-range"/>
 <t>
-   The "Accept-Language" request-header field can be used by user agents to
+   The "Accept-Language" header field can be used by user agents to
    indicate the set of natural languages that are preferred in the response.
    Language tags are defined in <xref target="language.tags"/>.
@@ -1736 +1736 @@
 <section title="Privacy Issues Connected to Accept Header Fields" anchor="privacy.issues.connected.to.accept.header.fields">
 <t>
-   Accept request-headers fields can reveal information about the user to all
+   Accept headers fields can reveal information about the user to all
    servers which are accessed. The Accept-Language header field in particular
    can reveal information the user would consider to be of a private
@@ -1750 +1750 @@
    to omit the sending of Accept-Language header fields by default, and to ask
    the user whether or not to start sending Accept-Language header fields to a
-   server if it detects, by looking for any Vary response-header fields
+   server if it detects, by looking for any Vary header fields
    generated by the server, that such sending could improve the quality
    of service.
@@ -2526 +2526 @@
 <t>
    HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages &MAY;
-   include a single MIME-Version general-header field to indicate what
+   include a single MIME-Version header field to indicate what
    version of the MIME protocol was used to construct the message. Use
    of the MIME-Version header field indicates that the message is in

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -229 +229 @@
    A future draft will reorganize the sections to better reflect the content.
    In particular, the sections on resource metadata will be discussed first
-   and then followed by each conditional request-header field, concluding with a
+   and then followed by each conditional request header field, concluding with a
    definition of precedence and the expectation of ordering strong validator
    checks before weak validator checks.  It is likely that more content from
@@ -442 +442 @@
   <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
 <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. This response
    code allows the client to place preconditions on the current resource
@@ -730 +730 @@
   <x:anchor-alias value="ETag-v"/>
 <t>
-   The "ETag" response-header field provides the current value of the
+   The "ETag" header field provides the current value of the
    entity-tag (see <xref target="entity.tags"/>) for one representation of
    the target resource.  An entity-tag
@@ -774 +774 @@
   <x:anchor-alias value="If-Match-v"/>
 <t>
-   The "If-Match" request-header field is used to make a request method
+   The "If-Match" header field is used to make a request method
    conditional. A client that has one or more representations previously
    obtained from the resource can verify that one of those representations is
@@ -844 +844 @@
   <x:anchor-alias value="If-Modified-Since-v"/>
 <t>
-   The "If-Modified-Since" request-header field is used to make a request 
+   The "If-Modified-Since" header field is used to make a request 
    method conditional by date: if the representation that would have been
    transferred in a 200 response to a GET request has not been modified since
@@ -885 +885 @@
    information with a minimum amount of transaction overhead.
   <list><t>
-      <x:h>Note:</x:h> The Range request-header field modifies the meaning of If-Modified-Since;
+      <x:h>Note:</x:h> The Range header field modifies the meaning of If-Modified-Since;
       see &header-range; for full details.
     </t><t>
@@ -929 +929 @@
   <x:anchor-alias value="If-None-Match-v"/>
 <t>
-   The "If-None-Match" request-header field is used to make a request method
+   The "If-None-Match" header field is used to make a request method
    conditional. A client that has one or more representations previously
    obtained from the resource can verify that none of those representations is
@@ -1008 +1008 @@
   <x:anchor-alias value="If-Unmodified-Since-v"/>
 <t>
-   The "If-Unmodified-Since" request-header field is used to make a request
+   The "If-Unmodified-Since" header field is used to make a request
    method conditional.  If the representation that would have been transferred
    in a 200 response to a GET request on the same resource has not been modified

draft-ietf-httpbis/latest/p5-range.xml

@@ -417 +417 @@
 <t>
    A server &SHOULD; return a response with this status code if a request
-   included a Range request-header field (<xref target="header.range"/>), and none of
+   included a Range header field (<xref target="header.range"/>), and none of
    the ranges-specifier values in this field overlap the current extent
    of the selected resource, and the request did not include an If-Range
-   request-header field (<xref target="header.if-range"/>). (For byte-ranges,
+   header field (<xref target="header.if-range"/>). (For byte-ranges,
    this means that the first-byte-pos of all of the byte-range-spec values were
    greater than the current length of the selected resource.)
@@ -474 +474 @@
   <x:anchor-alias value="acceptable-ranges"/>
 <t>
-   The "Accept-Ranges" response-header field allows a resource to indicate
+   The "Accept-Ranges" header field allows a resource to indicate
    its acceptance of range requests.
 </t>
@@ -643 +643 @@
 <t>
    If the server receives a request (other than one including an If-Range
-   request-header field) with an unsatisfiable Range request-header
+   header field) with an unsatisfiable Range header
    field (that is, all of whose byte-range-spec values have a
    first-byte-pos value greater than the current length of the selected
@@ -653 +653 @@
     <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested
     range not satisfiable) response instead of a 200 (OK) response for
-    an unsatisfiable Range request-header field, since not all servers
-    implement this request-header field.
+    an unsatisfiable Range header field, since not all servers
+    implement this header field.
   </t>
 </x:note>
@@ -667 +667 @@
    If a client has a partial copy of a representation in its cache, and wishes
    to have an up-to-date copy of the entire representation in its cache, it
-   could use the Range request-header field with a conditional GET (using
+   could use the Range header field with a conditional GET (using
    either or both of If-Unmodified-Since and If-Match.) However, if the
    condition fails because the representation has been modified, the client
@@ -674 +674 @@
 </t>
 <t>
-   The "If-Range" request-header field allows a client to "short-circuit" the second
+   The "If-Range" header field allows a client to "short-circuit" the second
    request. Informally, its meaning is "if the representation is unchanged, send
    me the part(s) that I am missing; otherwise, send me the entire new
@@ -826 +826 @@
   <x:anchor-alias value="other-range-set"/>
 <t>
-   The "Range" request-header field defines the GET method (conditional or
+   The "Range" header field defines the GET method (conditional or
    not) to request one or more sub-ranges of the response representation body, instead
    of the entire representation body.

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

@@ -522 +522 @@
       <t>the request method associated with the stored response allows it to
       be used for the presented request, and</t>
-      <t>selecting request-header fields nominated by the stored response (if any)
+      <t>selecting header fields nominated by the stored response (if any)
       match those presented (see <xref target="caching.negotiated.responses"
       />), and</t>
@@ -690 +690 @@
 <section anchor="age.calculations" title="Calculating Age">
 <t>
-   HTTP/1.1 uses the Age response-header field to convey the estimated age of the
+   HTTP/1.1 uses the Age header field to convey the estimated age of the
    response message when obtained from a cache. The Age field value is the
    cache's estimate of the amount of time since the response was generated or
@@ -940 +940 @@
    When a cache receives a request that can be satisfied by a stored response
    that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT;
-   use that response unless all of the selecting request-header fields nominated by
+   use that response unless all of the selecting header fields nominated by
    the Vary header field match in both the original request (i.e., that associated
    with the stored response), and the presented request.
 </t>
 <t>
-   The selecting request-header fields from two requests are defined to match if and
+   The selecting header fields from two requests are defined to match if and
    only if those in the first request can be transformed to those in the
    second request by applying any of the following:
@@ -953 +953 @@
       </t>
       <t>
-         combining multiple message-header fields with the same field name
+         combining multiple header fields with the same field name
          (see &header-fields;)
       </t>
@@ -975 +975 @@
 </t>
 <t>
-   The stored response with matching selecting request-header fields is known as the
+   The stored response with matching selecting header fields is known as the
    selected response.
 </t>
@@ -1040 +1040 @@
    <x:anchor-alias value="age-value"/>
 <t>
-   The "Age" response-header field conveys the sender's estimate of the amount
+   The "Age" header field conveys the sender's estimate of the amount
    of time since the response was generated or successfully validated at the
    origin server. Age values are calculated as specified in <xref
@@ -1081 +1081 @@
    <x:anchor-alias value="cache-response-directive"/>
 <t>
-   The "Cache-Control" general-header field is used to specify directives for
+   The "Cache-Control" header field is used to specify directives for
    caches along the request/response chain. Such cache directives are
    unidirectional in that the presence of a directive in a request does not
@@ -1506 +1506 @@
    <x:anchor-alias value="pragma-directive"/>
 <t>
-   The "Pragma" general-header field is used to include
+   The "Pragma" header field is used to include
    implementation-specific directives that might apply to any recipient along
    the request/response chain. All pragma directives specify optional behavior
@@ -1532 +1532 @@
    <t>
       <x:h>Note:</x:h> Because the meaning of "Pragma: no-cache" as a
-      response-header field is not actually specified, it does not provide a
+      header field is not actually specified, it does not provide a
       reliable replacement for "Cache-Control: no-cache" in a response.
    </t>
@@ -1548 +1548 @@
    <x:anchor-alias value="Vary-v"/>
 <t>
-   The "Vary" response-header field conveys the set of request-header fields
+   The "Vary" header field conveys the set of header fields
    that were used to select the representation.
 </t>
@@ -1569 +1569 @@
 <t>
    The set of header fields named by the Vary field value is known as the
-   selecting request-header fields.
+   selecting header fields.
 </t>
 <t>
@@ -1583 +1583 @@
 <t>
    A Vary field value of "*" signals that unspecified parameters not limited
-   to the request-header fields (e.g., the network address of the client), play a
+   to the header fields (e.g., the network address of the client), play a
    role in the selection of the response representation; therefore, a cache
    cannot determine whether this response is appropriate. A proxy &MUST-NOT;
@@ -1589 +1589 @@
 </t>
 <t>
-   The field-names given are not limited to the set of standard request-header
+   The field-names given are not limited to the set of standard header
    fields defined by this specification. Field names are case-insensitive.
 </t>
@@ -1605 +1605 @@
    <x:anchor-alias value="warn-text"/>
 <t>
-   The "Warning" general-header field is used to carry additional information
+   The "Warning" header field is used to carry additional information
    about the status or transformation of a message that might not be reflected
    in the message. This information is typically used to warn about possible

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

@@ -469 +469 @@
   <x:anchor-alias value="Authorization-v"/>
 <t>
-   The "Authorization" request-header field allows a user agent to authenticate
+   The "Authorization" header field allows a user agent to authenticate
    itself with a server &mdash; usually, but not necessarily, after receiving a 401
    (Unauthorized) response. Its value consists of credentials containing 
@@ -499 +499 @@
          subsequent request. But (if the specified maximum age has
          passed) a proxy cache &MUST; first revalidate it with the origin
-         server, using the request-header fields from the new request to allow
+         server, using the header fields from the new request to allow
          the origin server to authenticate the new request. (This is the
          defined behavior for s-maxage.) If the response includes "s-maxage=0",
@@ -509 +509 @@
          subsequent request. But if the response is stale, all caches
          &MUST; first revalidate it with the origin server, using the
-         request-header fields from the new request to allow the origin server
+         header fields from the new request to allow the origin server
          to authenticate the new request.</t>
 
@@ -524 +524 @@
   <x:anchor-alias value="Proxy-Authenticate-v"/>
 <t>
-   The "Proxy-Authenticate" response-header field consists of a challenge that
+   The "Proxy-Authenticate" header field consists of a challenge that
    indicates the authentication scheme and parameters applicable to the proxy
    for this effective request URI (&effective-request-uri;). It &MUST; be included as part
@@ -550 +550 @@
   <x:anchor-alias value="Proxy-Authorization-v"/>
 <t>
-   The "Proxy-Authorization" request-header field allows the client to
+   The "Proxy-Authorization" header field allows the client to
    identify itself (or its user) to a proxy which requires
    authentication. Its value consists of
@@ -579 +579 @@
   <x:anchor-alias value="WWW-Authenticate-v"/>
 <t>
-   The "WWW-Authenticate" response-header field consists of at least one
+   The "WWW-Authenticate" header field consists of at least one
    challenge that indicates the authentication scheme(s) and parameters
    applicable to the effective request URI (&effective-request-uri;). It &MUST; be included in 401