From: Brian Warner 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/components/com_hotproperty/%22doc.html/architecture.txt?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