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

Timestamp:

16/12/12 03:46:23 (8 years ago)

Author:

fielding@…

Message:

editorial fixes in methods; use send instead of return, sent instead of returned; partly addresses #419

File:

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

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

@@ -273 +273 @@
    header field, it &SHOULD-NOT; include other representation header fields.
    Otherwise, the response &MUST; include all of the representation header
-   fields that would have been returned with a <x:ref>200 (OK)</x:ref> response
+   fields that would have been sent with a <x:ref>200 (OK)</x:ref> response
    to the same request.
 </t>
@@ -286 +286 @@
   <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/>
 <t>
-   A server &SHOULD; return a response with this status code if a request
+   A server &SHOULD; send a response with this status code if a request
    included a <x:ref>Range</x:ref> header field (<xref target="header.range"/>),
    and none of the ranges-specifier values in this field overlap the current
@@ -296 +296 @@
 </t>
 <t>
-   When this status code is returned for a byte-range request, the
+   When this status code is sent for a byte-range request, the
    response &SHOULD; include a <x:ref>Content-Range</x:ref> header field
    specifying the current length of the representation (see <xref target="header.content-range"/>).
@@ -359 +359 @@
 <t>
    When a client asks for multiple ranges in one request, the
-   server &SHOULD; return them in the order that they appeared in the
+   server &SHOULD; send them in the order that they appeared in the
    request.
 </t>
@@ -558 +558 @@
    syntactically invalid, or if it might be seen as a denial-of-service
    attack), the server &SHOULD; treat the request as if the invalid <x:ref>Range</x:ref>
-   header field did not exist. (Normally, this means return a <x:ref>200 (OK)</x:ref>
+   header field did not exist. (Normally, this means send a <x:ref>200 (OK)</x:ref>
    response containing the full representation).
 </t>
@@ -690 +690 @@
    suffix-length, then the byte-range-set is satisfiable.
    Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
-   is unsatisfiable, the server &SHOULD; return a response with a 
+   is unsatisfiable, the server &SHOULD; send a response with a 
    <x:ref>416 (Requested Range Not Satisfiable)</x:ref> status code. Otherwise, the server
-   &SHOULD; return a response with a <x:ref>206 (Partial Content)</x:ref> status code
+   &SHOULD; send a response with a <x:ref>206 (Partial Content)</x:ref> status code
    containing the satisfiable ranges of the representation.
 </t>
@@ -768 +768 @@
   <list style="symbols">
      <t>The presence of a Range header field in an unconditional GET modifies
-        what is returned if the GET is otherwise successful. In other
+        what is sent if the GET is otherwise successful. In other
         words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref>
         instead of <x:ref>200 (OK)</x:ref>.</t>
@@ -776 +776 @@
         <x:ref>If-None-Match</x:ref>, or one or both of
         <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies
-        what is returned if the GET is otherwise successful and the
+        what is sent if the GET is otherwise successful and the
         condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref>
-        response returned if the conditional is false.</t>
+        response sent if the conditional is false.</t>
   </list>
 </t>
@@ -789 +789 @@
    If a proxy that supports ranges receives a Range request, forwards 
    the request to an inbound server, and receives an entire representation in
-   reply, it &MAY; only return the requested range to its client. 
+   reply, it &MAY; only send the requested range to its client. 
 </t>
 </section>
@@ -1307 +1307 @@
 </t>
 <t>
-  Servers are given more leeway in what they return to a range request,
+  Servers are given more leeway in what they send to a range request,
   in order to mitigate malicious (or just greedy) clients.
 </t>
@@ -1371 +1371 @@
 <x:ref>Content-Range</x:ref> = byte-content-range-spec / other-content-range-spec
 
-<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 8.1.1.1&gt;
+<x:ref>HTTP-date</x:ref> = &lt;HTTP-date, defined in [Part2], Section 7.1.1.1&gt;
 
 <x:ref>If-Range</x:ref> = entity-tag / HTTP-date