From: Brian Warner <warner@lothar.com>
Date: Tue, 28 Jul 2015 20:28:36 +0000 (-0700)
Subject: improve HTTP byte-range docs
X-Git-Tag: allmydata-tahoe-1.10.2b1~5
X-Git-Url: https://git.rkrishnan.org/pf/content/en/service/@manifest?a=commitdiff_plain;h=259ba07a5ef433bd779bc10833413cdfe1d50abe;p=tahoe-lafs%2Ftahoe-lafs.git

improve HTTP byte-range docs
---

diff --git a/docs/frontends/webapi.rst b/docs/frontends/webapi.rst
index c3dcea6c..6b04429a 100644
--- a/docs/frontends/webapi.rst
+++ b/docs/frontends/webapi.rst
@@ -348,10 +348,15 @@ Reading a File
 ``GET /uri/$DIRCAP/[SUBDIRS../]FILENAME``
 
  This will retrieve the contents of the given file. The HTTP response body
- will contain the sequence of bytes that make up the file. The "Range:"
- header can be used to restrict which portions of the file are returned (see
- RFC 2616 section 14.35.1 "Byte Ranges"), however Tahoe only supports a
- single "bytes" range and never provides a `multipart/byteranges` response.
+ will contain the sequence of bytes that make up the file.
+
+ The "Range:" header can be used to restrict which portions of the file are
+ returned (see RFC 2616 section 14.35.1 "Byte Ranges"), however Tahoe only
+ supports a single "bytes" range and never provides a `multipart/byteranges`
+ response. An attempt to begin a read past the end of the file will provoke a
+ 416 Requested Range Not Satisfiable error, but normal overruns (reads which
+ start at the beginning or middle and go beyond the end) are simply
+ truncated.
 
  To view files in a web browser, you may want more control over the
  Content-Type and Content-Disposition headers. Please see the next section