ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-01-19 11:16:24 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

update webapi.rst's View/Download File docs

Browse Source 
• mark "/file/" as a synonym for "/named/" to be deprecated (fixes #1903)
• move the options common to all three forms to the bottom and dedent them
• name the protocol/format as "LAFS" and the implementation/client "Tahoe"
• reflow (with fill-column 77)
This commit is contained in:
Zooko O'Whielacronx 2013-01-04 17:39:46 -07:00 committed by Brian Warner
parent f665d0690e
commit 3e7346100f
1 changed files with 24 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
docs/frontends/webapi.rst
View File

@ -1043,26 +1043,6 @@ Viewing/Downloading a File
This will retrieve the contents of the given file. The HTTP response body
will contain the sequence of bytes that make up the file.
If you want the HTTP response to include a useful Content-Type header,
either use the second form (which starts with a $DIRCAP), or add a
"filename=foo" query argument, like "GET /uri/$FILECAP?filename=foo.jpg".
The bare "GET /uri/$FILECAP" does not give the Tahoe node enough information
to determine a Content-Type (since Tahoe immutable files are merely
sequences of bytes, not typed+named file objects).
If the URL has both filename= and "save=true" in the query arguments, then
the server to add a "Content-Disposition: attachment" header, along with a
filename= parameter. When a user clicks on such a link, most browsers will
offer to let the user save the file instead of displaying it inline (indeed,
most browsers will refuse to display it inline). "true", "t", "1", and other
case-insensitive equivalents are all treated the same.
Character-set handling in URLs and HTTP headers is a :ref:`dubious
art<urls-and-utf8>`. For maximum compatibility, Tahoe simply copies the
bytes from the filename= argument into the Content-Disposition header's
filename= parameter, without trying to interpret them in any particular way.
``GET /named/$FILECAP/FILENAME``
This is an alternate download form which makes it easier to get the correct
@ -1074,7 +1054,30 @@ Viewing/Downloading a File
directory cap after the /named/ prefix.
URLs may also use /file/$FILECAP/FILENAME as a synonym for
/named/$FILECAP/FILENAME.
/named/$FILECAP/FILENAME. The use of "/file/" is deprecated in favor of
"/named/" and support for "/file/" will be removed in a future release of
Tahoe-LAFS..
If you want the HTTP response to include a useful Content-Type header, either
use the second or third form or add a "filename=foo" query argument, like
"GET /uri/$FILECAP?filename=foo.jpg". The bare "GET /uri/$FILECAP" does not
give the Tahoe node enough information to determine a Content-Type (since
LAFS immutable files are merely sequences of bytes, not typed and named file
objects).
If the URL has both filename= and "save=true" in the query arguments, then
the server to add a "Content-Disposition: attachment" header, along with a
filename= parameter. When a user clicks on such a link, most browsers will
offer to let the user save the file instead of displaying it inline (indeed,
most browsers will refuse to display it inline). "true", "t", "1", and other
case-insensitive equivalents are all treated the same.
Character-set handling in URLs and HTTP headers is a dubious art [1]_. For
maximum compatibility, Tahoe simply copies the bytes from the filename=
argument into the Content-Disposition header's filename= parameter, without
trying to interpret them in any particular way.
Getting Information About a File Or Directory (as HTML)
-------------------------------------------------------