Changeset 994 for draft-ietf-httpbis/latest/p5-range.xml

Timestamp:

07/09/10 11:46:12 (13 years ago)

Author:

julian.reschke@…

Message:

Uniform use of 'header field' (see #234)

File:

• draft-ietf-httpbis/latest/p5-range.xml (modified) (13 diffs)

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

@@ -334 +334 @@
 <t>
   If a range unit is not understood in a request, a server &MUST; ignore
-  the whole Range header (<xref target="header.range" />).
+  the whole Range header field (<xref target="header.range"/>).
   If a range unit is not understood in a response, an intermediary 
   &SHOULD; pass the response to the client; a client &MUST; fail.
@@ -403 +403 @@
 <t>
    A cache &MUST-NOT; combine a 206 response with other previously cached
-   content if the ETag or Last-Modified headers do not match exactly,
+   content if the ETag or Last-Modified header fields do not match exactly,
    see <xref target="combining.byte.ranges"/>.
 </t>
 <t>
-   A cache that does not support the Range and Content-Range headers
+   A cache that does not support the Range and Content-Range header fields
    &MUST-NOT; cache 206 (Partial Content) responses. Furthermore,
    if a response uses a range unit that is not understood by the cache,
@@ -492 +492 @@
 <t>
       but are not required to do so. Clients &MAY; generate range
-      requests without having received this header for the resource
+      requests without having received this header field for the resource
       involved. Range units are defined in <xref target="range.units"/>.
 </t>
@@ -546 +546 @@
 </artwork></figure>
 <t>
-   The header &SHOULD; indicate the total length of the full representation,
+   The header field &SHOULD; indicate the total length of the full representation,
    unless this length is unknown or difficult to determine. The asterisk
    "*" character means that the instance-length is unknown at the time
@@ -606 +606 @@
    example, a response to a request for a single range, or to a request
    for a set of ranges that overlap without any holes), this content is
-   transmitted with a Content-Range header, and a Content-Length header
-   showing the number of bytes actually transferred. For example,
+   transmitted with a Content-Range header field, and a Content-Length header
+   field showing the number of bytes actually transferred. For example,
 </t>
 <figure><artwork type="example">
@@ -655 +655 @@
     <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, since not all servers
-    implement this request-header.
+    an unsatisfiable Range request-header field, since not all servers
+    implement this request-header field.
   </t>
 </x:note>
@@ -669 +669 @@
    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 with a conditional GET (using
+   could use the Range request-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
@@ -687 +687 @@
 <t>
    If the client has no entity-tag for a representation, but does have a Last-Modified
-   date, it &MAY; use that date in an If-Range header. (The
+   date, it &MAY; use that date in an If-Range header field. (The
    server can distinguish between a valid HTTP-date and any form of
    entity-tag by examining no more than two characters.) The If-Range
-   header &SHOULD; only be used together with a Range header, and &MUST; be
-   ignored if the request does not include a Range header, or if the
+   header field &SHOULD; only be used together with a Range header field, and &MUST; be
+   ignored if the request does not include a Range header field, or if the
    server does not support the sub-range operation.
 </t>
 <t>
-   If the entity-tag given in the If-Range header matches the current
+   If the entity-tag given in the If-Range header field matches the current
    cache validator for the representation, then the server &SHOULD; provide the
    specified sub-range of the representation using a 206 (Partial Content)
@@ -840 +840 @@
 </artwork></figure>
 <t>
-   A server &MAY; ignore the Range header. However, HTTP/1.1 origin
+   A server &MAY; ignore the Range header field. However, HTTP/1.1 origin
    servers and intermediate caches ought to support byte ranges when
    possible, since Range supports efficient recovery from partially
@@ -847 +847 @@
 </t>
 <t>
-   If the server supports the Range header and the specified range or
+   If the server supports the Range header field and the specified range or
    ranges are appropriate for the representation:
   <list style="symbols">
-     <t>The presence of a Range header in an unconditional GET modifies
+     <t>The presence of a Range header field in an unconditional GET modifies
         what is returned if the GET is otherwise successful. In other
         words, the response carries a status code of 206 (Partial
         Content) instead of 200 (OK).</t>
 
-     <t>The presence of a Range header in a conditional GET (a request
+     <t>The presence of a Range header field in a conditional GET (a request
         using one or both of If-Modified-Since and If-None-Match, or
         one or both of If-Unmodified-Since and If-Match) modifies what
@@ -865 +865 @@
 <t>
    In some cases, it might be more appropriate to use the If-Range
-   header (see <xref target="header.if-range"/>) in addition to the Range header.
+   header field (see <xref target="header.if-range"/>) in addition to the Range
+   header field.
 </t>
 <t>
@@ -1498 +1499 @@
 <section title="Since draft-ietf-httpbis-p5-range-02" anchor="changes.since.02">
 <t>
-  Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
+  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
   <list style="symbols"> 
     <t>
-      Reference RFC 3984, and update header registrations for headers defined
+      Reference RFC 3984, and update header field registrations for headers defined
       in this document.
     </t>
@@ -1535 +1536 @@
     <t>
       Rewrite ABNFs to spell out whitespace rules, factor out
-      header value format definitions.
+      header field value format definitions.
     </t>
   </list>