1 ==========================
2 The Tahoe REST-ful Web API
3 ==========================
5 1. `Enabling the web-API port`_
6 2. `Basic Concepts: GET, PUT, DELETE, POST`_
11 4. `Slow Operations, Progress, and Cancelling`_
12 5. `Programmatic Operations`_
15 2. `Writing/Uploading a File`_
16 3. `Creating a New Directory`_
17 4. `Getting Information About A File Or Directory (as JSON)`_
18 5. `Attaching an Existing File or Directory by its read- or write-cap`_
19 6. `Adding Multiple Files or Directories to a Parent Directory at Once`_
20 7. `Unlinking a File or Directory`_
22 6. `Browser Operations: Human-Oriented Interfaces`_
24 1. `Viewing A Directory (as HTML)`_
25 2. `Viewing/Downloading a File`_
26 3. `Getting Information About A File Or Directory (as HTML)`_
27 4. `Creating a Directory`_
28 5. `Uploading a File`_
29 6. `Attaching An Existing File Or Directory (by URI)`_
30 7. `Unlinking A Child`_
31 8. `Renaming A Child`_
33 10. `Debugging and Testing Features`_
35 7. `Other Useful Pages`_
36 8. `Static Files in /public_html`_
37 9. `Safety and Security Issues -- Names vs. URIs`_
38 10. `Concurrency Issues`_
39 11. `Access Blacklist`_
42 Enabling the web-API port
43 =========================
45 Every Tahoe node is capable of running a built-in HTTP server. To enable
46 this, just write a port number into the "[node]web.port" line of your node's
47 tahoe.cfg file. For example, writing "web.port = 3456" into the "[node]"
48 section of $NODEDIR/tahoe.cfg will cause the node to run a webserver on port
51 This string is actually a Twisted "strports" specification, meaning you can
52 get more control over the interface to which the server binds by supplying
53 additional arguments. For more details, see the documentation on
54 `twisted.application.strports
55 <http://twistedmatrix.com/documents/current/api/twisted.application.strports.html>`_.
57 Writing "tcp:3456:interface=127.0.0.1" into the web.port line does the same
58 but binds to the loopback interface, ensuring that only the programs on the
59 local host can connect. Using "ssl:3456:privateKey=mykey.pem:certKey=cert.pem"
62 This webport can be set when the node is created by passing a --webport
63 option to the 'tahoe create-node' command. By default, the node listens on
64 port 3456, on the loopback (127.0.0.1) interface.
67 Basic Concepts: GET, PUT, DELETE, POST
68 ======================================
70 As described in `docs/architecture.rst <../architecture.rst>`_, each file
71 and directory in a Tahoe virtual filesystem is referenced by an identifier
72 that combines the designation of the object with the authority to do something
73 with it (such as read or modify the contents). This identifier is called a
74 "read-cap" or "write-cap", depending upon whether it enables read-only or
75 read-write access. These "caps" are also referred to as URIs (which may be
76 confusing because they are not currently `RFC3986
77 <http://tools.ietf.org/html/rfc3986>`_-compliant URIs).
79 The Tahoe web-based API is "REST-ful", meaning it implements the concepts of
80 "REpresentational State Transfer": the original scheme by which the World
81 Wide Web was intended to work. Each object (file or directory) is referenced
82 by a URL that includes the read- or write- cap. HTTP methods (GET, PUT, and
83 DELETE) are used to manipulate these objects. You can think of the URL as a
84 noun, and the method as a verb.
86 In REST, the GET method is used to retrieve information about an object, or
87 to retrieve some representation of the object itself. When the object is a
88 file, the basic GET method will simply return the contents of that file.
89 Other variations (generally implemented by adding query parameters to the
90 URL) will return information about the object, such as metadata. GET
91 operations are required to have no side-effects.
93 PUT is used to upload new objects into the filesystem, or to replace an
94 existing link or the contents of a mutable file. DELETE is used to unlink
95 objects from directories. Both PUT and DELETE are required to be idempotent:
96 performing the same operation multiple times must have the same side-effects
97 as only performing it once.
99 POST is used for more complicated actions that cannot be expressed as a GET,
100 PUT, or DELETE. POST operations can be thought of as a method call: sending
101 some message to the object referenced by the URL. In Tahoe, POST is also used
102 for operations that must be triggered by an HTML form (including upload and
103 unlinking), because otherwise a regular web browser has no way to accomplish
104 these tasks. In general, everything that can be done with a PUT or DELETE can
105 also be done with a POST.
107 Tahoe's web API is designed for two different kinds of consumer. The first is
108 a program that needs to manipulate the virtual file system. Such programs are
109 expected to use the RESTful interface described above. The second is a human
110 using a standard web browser to work with the filesystem. This user is given
111 a series of HTML pages with links to download files, and forms that use POST
112 actions to upload, rename, and unlink files.
114 When an error occurs, the HTTP response code will be set to an appropriate
115 400-series code (like 404 Not Found for an unknown childname, or 400 Bad Request
116 when the parameters to a web-API operation are invalid), and the HTTP response
117 body will usually contain a few lines of explanation as to the cause of the
118 error and possible responses. Unusual exceptions may result in a 500 Internal
119 Server Error as a catch-all, with a default response body containing
120 a Nevow-generated HTML-ized representation of the Python exception stack trace
121 that caused the problem. CLI programs which want to copy the response body to
122 stderr should provide an "Accept: text/plain" header to their requests to get
123 a plain text stack trace instead. If the Accept header contains ``*/*``, or
124 ``text/*``, or text/html (or if there is no Accept header), HTML tracebacks will
131 Tahoe uses a variety of read- and write- caps to identify files and
132 directories. The most common of these is the "immutable file read-cap", which
133 is used for most uploaded files. These read-caps look like the following::
135 URI:CHK:ime6pvkaxuetdfah2p2f35pe54:4btz54xk3tew6nd4y2ojpxj4m6wxjqqlwnztgre6gnjgtucd5r4a:3:10:202
137 The next most common is a "directory write-cap", which provides both read and
138 write access to a directory, and look like this::
140 URI:DIR2:djrdkfawoqihigoett4g6auz6a:jx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq
142 There are also "directory read-caps", which start with "URI:DIR2-RO:", and
143 give read-only access to a directory. Finally there are also mutable file
144 read- and write- caps, which start with "URI:SSK", and give access to mutable
147 (Later versions of Tahoe will make these strings shorter, and will remove the
148 unfortunate colons, which must be escaped when these caps are embedded in
151 To refer to any Tahoe object through the web API, you simply need to combine
152 a prefix (which indicates the HTTP server to use) with the cap (which
153 indicates which object inside that server to access). Since the default Tahoe
154 webport is 3456, the most common prefix is one that will use a local node
155 listening on this port::
157 http://127.0.0.1:3456/uri/ + $CAP
159 So, to access the directory named above (which happens to be the
160 publically-writeable sample directory on the Tahoe test grid, described at
161 http://allmydata.org/trac/tahoe/wiki/TestGrid), the URL would be::
163 http://127.0.0.1:3456/uri/URI%3ADIR2%3Adjrdkfawoqihigoett4g6auz6a%3Ajx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq/
165 (note that the colons in the directory-cap are url-encoded into "%3A"
168 Likewise, to access the file named above, use::
170 http://127.0.0.1:3456/uri/URI%3ACHK%3Aime6pvkaxuetdfah2p2f35pe54%3A4btz54xk3tew6nd4y2ojpxj4m6wxjqqlwnztgre6gnjgtucd5r4a%3A3%3A10%3A202
172 In the rest of this document, we'll use "$DIRCAP" as shorthand for a read-cap
173 or write-cap that refers to a directory, and "$FILECAP" to abbreviate a cap
174 that refers to a file (whether mutable or immutable). So those URLs above can
177 http://127.0.0.1:3456/uri/$DIRCAP/
178 http://127.0.0.1:3456/uri/$FILECAP
180 The operation summaries below will abbreviate these further, by eliding the
181 server prefix. They will be displayed like this::
190 Tahoe directories contain named child entries, just like directories in a regular
191 local filesystem. These child entries, called "dirnodes", consist of a name,
192 metadata, a write slot, and a read slot. The write and read slots normally contain
193 a write-cap and read-cap referring to the same object, which can be either a file
194 or a subdirectory. The write slot may be empty (actually, both may be empty,
195 but that is unusual).
197 If you have a Tahoe URL that refers to a directory, and want to reference a
198 named child inside it, just append the child name to the URL. For example, if
199 our sample directory contains a file named "welcome.txt", we can refer to
202 http://127.0.0.1:3456/uri/$DIRCAP/welcome.txt
204 (or http://127.0.0.1:3456/uri/URI%3ADIR2%3Adjrdkfawoqihigoett4g6auz6a%3Ajx5mplfpwexnoqff7y5e4zjus4lidm76dcuarpct7cckorh2dpgq/welcome.txt)
206 Multiple levels of subdirectories can be handled this way::
208 http://127.0.0.1:3456/uri/$DIRCAP/tahoe-source/docs/architecture.rst
210 In this document, when we need to refer to a URL that references a file using
211 this child-of-some-directory format, we'll use the following string::
213 /uri/$DIRCAP/[SUBDIRS../]FILENAME
215 The "[SUBDIRS../]" part means that there are zero or more (optional)
216 subdirectory names in the middle of the URL. The "FILENAME" at the end means
217 that this whole URL refers to a file of some sort, rather than to a
220 When we need to refer specifically to a directory in this way, we'll write::
222 /uri/$DIRCAP/[SUBDIRS../]SUBDIR
225 Note that all components of pathnames in URLs are required to be UTF-8
226 encoded, so "resume.doc" (with an acute accent on both E's) would be accessed
229 http://127.0.0.1:3456/uri/$DIRCAP/r%C3%A9sum%C3%A9.doc
231 Also note that the filenames inside upload POST forms are interpreted using
232 whatever character set was provided in the conventional '_charset' field, and
233 defaults to UTF-8 if not otherwise specified. The JSON representation of each
234 directory contains native Unicode strings. Tahoe directories are specified to
235 contain Unicode filenames, and cannot contain binary strings that are not
236 representable as such.
238 All Tahoe operations that refer to existing files or directories must include
239 a suitable read- or write- cap in the URL: the web-API server won't add one
240 for you. If you don't know the cap, you can't access the file. This allows
241 the security properties of Tahoe caps to be extended across the web-API
245 Slow Operations, Progress, and Cancelling
246 =========================================
248 Certain operations can be expected to take a long time. The "t=deep-check",
249 described below, will recursively visit every file and directory reachable
250 from a given starting point, which can take minutes or even hours for
251 extremely large directory structures. A single long-running HTTP request is a
252 fragile thing: proxies, NAT boxes, browsers, and users may all grow impatient
253 with waiting and give up on the connection.
255 For this reason, long-running operations have an "operation handle", which
256 can be used to poll for status/progress messages while the operation
257 proceeds. This handle can also be used to cancel the operation. These handles
258 are created by the client, and passed in as a an "ophandle=" query argument
259 to the POST or PUT request which starts the operation. The following
260 operations can then be used to retrieve status:
262 ``GET /operations/$HANDLE?output=HTML (with or without t=status)``
264 ``GET /operations/$HANDLE?output=JSON (same)``
266 These two retrieve the current status of the given operation. Each operation
267 presents a different sort of information, but in general the page retrieved
270 * whether the operation is complete, or if it is still running
271 * how much of the operation is complete, and how much is left, if possible
273 Note that the final status output can be quite large: a deep-manifest of a
274 directory structure with 300k directories and 200k unique files is about
275 275MB of JSON, and might take two minutes to generate. For this reason, the
276 full status is not provided until the operation has completed.
278 The HTML form will include a meta-refresh tag, which will cause a regular
279 web browser to reload the status page about 60 seconds later. This tag will
280 be removed once the operation has completed.
282 There may be more status information available under
283 /operations/$HANDLE/$ETC : i.e., the handle forms the root of a URL space.
285 ``POST /operations/$HANDLE?t=cancel``
287 This terminates the operation, and returns an HTML page explaining what was
288 cancelled. If the operation handle has already expired (see below), this
289 POST will return a 404, which indicates that the operation is no longer
290 running (either it was completed or terminated). The response body will be
291 the same as a GET /operations/$HANDLE on this operation handle, and the
292 handle will be expired immediately afterwards.
294 The operation handle will eventually expire, to avoid consuming an unbounded
295 amount of memory. The handle's time-to-live can be reset at any time, by
296 passing a retain-for= argument (with a count of seconds) to either the
297 initial POST that starts the operation, or the subsequent GET request which
298 asks about the operation. For example, if a 'GET
299 /operations/$HANDLE?output=JSON&retain-for=600' query is performed, the
300 handle will remain active for 600 seconds (10 minutes) after the GET was
303 In addition, if the GET includes a release-after-complete=True argument, and
304 the operation has completed, the operation handle will be released
307 If a retain-for= argument is not used, the default handle lifetimes are:
309 * handles will remain valid at least until their operation finishes
310 * uncollected handles for finished operations (i.e. handles for
311 operations that have finished but for which the GET page has not been
312 accessed since completion) will remain valid for four days, or for
313 the total time consumed by the operation, whichever is greater.
314 * collected handles (i.e. the GET page has been retrieved at least once
315 since the operation completed) will remain valid for one day.
317 Many "slow" operations can begin to use unacceptable amounts of memory when
318 operating on large directory structures. The memory usage increases when the
319 ophandle is polled, as the results must be copied into a JSON string, sent
320 over the wire, then parsed by a client. So, as an alternative, many "slow"
321 operations have streaming equivalents. These equivalents do not use operation
322 handles. Instead, they emit line-oriented status results immediately. Client
323 code can cancel the operation by simply closing the HTTP connection.
326 Programmatic Operations
327 =======================
329 Now that we know how to build URLs that refer to files and directories in a
330 Tahoe virtual filesystem, what sorts of operations can we do with those URLs?
331 This section contains a catalog of GET, PUT, DELETE, and POST operations that
332 can be performed on these URLs. This set of operations are aimed at programs
333 that use HTTP to communicate with a Tahoe node. A later section describes
334 operations that are intended for web browsers.
340 ``GET /uri/$FILECAP``
342 ``GET /uri/$DIRCAP/[SUBDIRS../]FILENAME``
344 This will retrieve the contents of the given file. The HTTP response body
345 will contain the sequence of bytes that make up the file.
347 To view files in a web browser, you may want more control over the
348 Content-Type and Content-Disposition headers. Please see the next section
349 "Browser Operations", for details on how to modify these URLs for that
353 Writing/Uploading A File
354 ------------------------
356 ``PUT /uri/$FILECAP``
358 ``PUT /uri/$DIRCAP/[SUBDIRS../]FILENAME``
360 Upload a file, using the data from the HTTP request body, and add whatever
361 child links and subdirectories are necessary to make the file available at
362 the given location. Once this operation succeeds, a GET on the same URL will
363 retrieve the same contents that were just uploaded. This will create any
364 necessary intermediate subdirectories.
366 To use the /uri/$FILECAP form, $FILECAP must be a write-cap for a mutable file.
368 In the /uri/$DIRCAP/[SUBDIRS../]FILENAME form, if the target file is a
369 writeable mutable file, that file's contents will be overwritten
370 in-place. If it is a read-cap for a mutable file, an error will occur.
371 If it is an immutable file, the old file will be discarded, and a new
372 one will be put in its place. If the target file is a writable mutable
373 file, you may also specify an "offset" parameter -- a byte offset that
374 determines where in the mutable file the data from the HTTP request
375 body is placed. This operation is relatively efficient for MDMF mutable
376 files, and is relatively inefficient (but still supported) for SDMF
377 mutable files. If no offset parameter is specified, then the entire
378 file is replaced with the data from the HTTP request body. For an
379 immutable file, the "offset" parameter is not valid.
381 When creating a new file, you can control the type of file created by
382 specifying a format= argument in the query string. format=mdmf creates an MDMF
383 mutable file. format=sdmf creates an SDMF mutable file. format=chk creates an
384 immutable file. The value of the format argument is case-insensitive. For
385 compatibility with previous versions of Tahoe-LAFS, the webapi will also
386 accept a mutable=true argument in the query string. If mutable=true is given,
387 then the new file will be mutable, and its format will be the default mutable
388 file format, as configured on the Tahoe-LAFS node hosting the webapi server.
389 Use of mutable=true is discouraged; new code should use format= instead of
390 mutable=true. If neither format= nor mutable=true are given, the
391 newly-created file will be immutable.
393 This returns the file-cap of the resulting file. If a new file was created
394 by this method, the HTTP response code (as dictated by rfc2616) will be set
395 to 201 CREATED. If an existing file was replaced or modified, the response
398 Note that the 'curl -T localfile http://127.0.0.1:3456/uri/$DIRCAP/foo.txt'
399 command can be used to invoke this operation.
403 This uploads a file, and produces a file-cap for the contents, but does not
404 attach the file into the filesystem. No directories will be modified by
405 this operation. The file-cap is returned as the body of the HTTP response.
407 This method accepts format= and mutable=true as query string arguments, and
408 interprets those arguments in the same way as the linked forms of PUT
409 described immediately above.
411 Creating A New Directory
412 ------------------------
414 ``POST /uri?t=mkdir``
418 Create a new empty directory and return its write-cap as the HTTP response
419 body. This does not make the newly created directory visible from the
420 filesystem. The "PUT" operation is provided for backwards compatibility:
421 new code should use POST.
423 This supports a format= argument in the query string. The format=
424 argument, if specified, controls the format of the directory. format=mdmf
425 indicates that the directory should be stored as an MDMF file; format=sdmf
426 indicates that the directory should be stored as an SDMF file. The value of
427 the format= argument is case-insensitive. If no format= argument is
428 given, the directory's format is determined by the default mutable file
429 format, as configured on the Tahoe-LAFS node responding to the request.
431 ``POST /uri?t=mkdir-with-children``
433 Create a new directory, populated with a set of child nodes, and return its
434 write-cap as the HTTP response body. The new directory is not attached to
435 any other directory: the returned write-cap is the only reference to it.
437 The format of the directory can be controlled with the format= argument in
438 the query string, as described above.
440 Initial children are provided as the body of the POST form (this is more
441 efficient than doing separate mkdir and set_children operations). If the
442 body is empty, the new directory will be empty. If not empty, the body will
443 be interpreted as a UTF-8 JSON-encoded dictionary of children with which the
444 new directory should be populated, using the same format as would be
445 returned in the 'children' value of the t=json GET request, described below.
446 Each dictionary key should be a child name, and each value should be a list
447 of [TYPE, PROPDICT], where PROPDICT contains "rw_uri", "ro_uri", and
448 "metadata" keys (all others are ignored). For example, the PUT request body
452 "Fran\u00e7ais": [ "filenode", {
453 "ro_uri": "URI:CHK:...",
456 "ctime": 1202777696.7564139,
457 "mtime": 1202777696.7564139,
459 "linkcrtime": 1202777696.7564139,
460 "linkmotime": 1202777696.7564139
462 "subdir": [ "dirnode", {
463 "rw_uri": "URI:DIR2:...",
464 "ro_uri": "URI:DIR2-RO:...",
466 "ctime": 1202778102.7589991,
467 "mtime": 1202778111.2160511,
469 "linkcrtime": 1202777696.7564139,
470 "linkmotime": 1202777696.7564139
474 For forward-compatibility, a mutable directory can also contain caps in
475 a format that is unknown to the web-API server. When such caps are retrieved
476 from a mutable directory in a "ro_uri" field, they will be prefixed with
477 the string "ro.", indicating that they must not be decoded without
478 checking that they are read-only. The "ro." prefix must not be stripped
479 off without performing this check. (Future versions of the web-API server
480 will perform it where necessary.)
482 If both the "rw_uri" and "ro_uri" fields are present in a given PROPDICT,
483 and the web-API server recognizes the rw_uri as a write cap, then it will
484 reset the ro_uri to the corresponding read cap and discard the original
485 contents of ro_uri (in order to ensure that the two caps correspond to the
486 same object and that the ro_uri is in fact read-only). However this may not
487 happen for caps in a format unknown to the web-API server. Therefore, when
488 writing a directory the web-API client should ensure that the contents
489 of "rw_uri" and "ro_uri" for a given PROPDICT are a consistent
490 (write cap, read cap) pair if possible. If the web-API client only has
491 one cap and does not know whether it is a write cap or read cap, then
492 it is acceptable to set "rw_uri" to that cap and omit "ro_uri". The
493 client must not put a write cap into a "ro_uri" field.
495 The metadata may have a "no-write" field. If this is set to true in the
496 metadata of a link, it will not be possible to open that link for writing
497 via the SFTP frontend; see `<FTP-and-SFTP.rst>`_ for details.
498 Also, if the "no-write" field is set to true in the metadata of a link to
499 a mutable child, it will cause the link to be diminished to read-only.
501 Note that the web-API-using client application must not provide the
502 "Content-Type: multipart/form-data" header that usually accompanies HTML
503 form submissions, since the body is not formatted this way. Doing so will
504 cause a server error as the lower-level code misparses the request body.
506 Child file names should each be expressed as a Unicode string, then used as
507 keys of the dictionary. The dictionary should then be converted into JSON,
508 and the resulting string encoded into UTF-8. This UTF-8 bytestring should
509 then be used as the POST body.
511 ``POST /uri?t=mkdir-immutable``
513 Like t=mkdir-with-children above, but the new directory will be
514 deep-immutable. This means that the directory itself is immutable, and that
515 it can only contain objects that are treated as being deep-immutable, like
516 immutable files, literal files, and deep-immutable directories.
518 For forward-compatibility, a deep-immutable directory can also contain caps
519 in a format that is unknown to the web-API server. When such caps are retrieved
520 from a deep-immutable directory in a "ro_uri" field, they will be prefixed
521 with the string "imm.", indicating that they must not be decoded without
522 checking that they are immutable. The "imm." prefix must not be stripped
523 off without performing this check. (Future versions of the web-API server
524 will perform it where necessary.)
526 The cap for each child may be given either in the "rw_uri" or "ro_uri"
527 field of the PROPDICT (not both). If a cap is given in the "rw_uri" field,
528 then the web-API server will check that it is an immutable read-cap of a
529 *known* format, and give an error if it is not. If a cap is given in the
530 "ro_uri" field, then the web-API server will still check whether known
531 caps are immutable, but for unknown caps it will simply assume that the
532 cap can be stored, as described above. Note that an attacker would be
533 able to store any cap in an immutable directory, so this check when
534 creating the directory is only to help non-malicious clients to avoid
535 accidentally giving away more authority than intended.
537 A non-empty request body is mandatory, since after the directory is created,
538 it will not be possible to add more children to it.
540 ``POST /uri/$DIRCAP/[SUBDIRS../]SUBDIR?t=mkdir``
542 ``PUT /uri/$DIRCAP/[SUBDIRS../]SUBDIR?t=mkdir``
544 Create new directories as necessary to make sure that the named target
545 ($DIRCAP/SUBDIRS../SUBDIR) is a directory. This will create additional
546 intermediate mutable directories as necessary. If the named target directory
547 already exists, this will make no changes to it.
549 If the final directory is created, it will be empty.
551 This accepts a format= argument in the query string, which controls the
552 format of the named target directory, if it does not already exist. format=
553 is interpreted in the same way as in the POST /uri?t=mkdir form. Note that
554 format= only controls the format of the named target directory;
555 intermediate directories, if created, are created based on the default
556 mutable type, as configured on the Tahoe-LAFS server responding to the
559 This operation will return an error if a blocking file is present at any of
560 the parent names, preventing the server from creating the necessary parent
561 directory; or if it would require changing an immutable directory.
563 The write-cap of the new directory will be returned as the HTTP response
566 ``POST /uri/$DIRCAP/[SUBDIRS../]SUBDIR?t=mkdir-with-children``
568 Like /uri?t=mkdir-with-children, but the final directory is created as a
569 child of an existing mutable directory. This will create additional
570 intermediate mutable directories as necessary. If the final directory is
571 created, it will be populated with initial children from the POST request
572 body, as described above.
574 This accepts a format= argument in the query string, which controls the
575 format of the target directory, if the target directory is created as part
576 of the operation. format= is interpreted in the same way as in the POST/
577 uri?t=mkdir-with-children operation. Note that format= only controls the
578 format of the named target directory; intermediate directories, if created,
579 are created using the default mutable type setting, as configured on the
580 Tahoe-LAFS server responding to the request.
582 This operation will return an error if a blocking file is present at any of
583 the parent names, preventing the server from creating the necessary parent
584 directory; or if it would require changing an immutable directory; or if
585 the immediate parent directory already has a a child named SUBDIR.
587 ``POST /uri/$DIRCAP/[SUBDIRS../]SUBDIR?t=mkdir-immutable``
589 Like /uri?t=mkdir-immutable, but the final directory is created as a child
590 of an existing mutable directory. The final directory will be deep-immutable,
591 and will be populated with the children specified as a JSON dictionary in
592 the POST request body.
594 In Tahoe 1.6 this operation creates intermediate mutable directories if
595 necessary, but that behaviour should not be relied on; see ticket #920.
597 This operation will return an error if the parent directory is immutable,
598 or already has a child named SUBDIR.
600 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir&name=NAME``
602 Create a new empty mutable directory and attach it to the given existing
603 directory. This will create additional intermediate directories as necessary.
605 This accepts a format= argument in the query string, which controls the
606 format of the named target directory, if it does not already exist. format=
607 is interpreted in the same way as in the POST /uri?t=mkdir form. Note that
608 format= only controls the format of the named target directory;
609 intermediate directories, if created, are created based on the default
610 mutable type, as configured on the Tahoe-LAFS server responding to the
613 This operation will return an error if a blocking file is present at any of
614 the parent names, preventing the server from creating the necessary parent
615 directory, or if it would require changing any immutable directory.
617 The URL of this operation points to the parent of the bottommost new directory,
618 whereas the /uri/$DIRCAP/[SUBDIRS../]SUBDIR?t=mkdir operation above has a URL
619 that points directly to the bottommost new directory.
621 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir-with-children&name=NAME``
623 Like /uri/$DIRCAP/[SUBDIRS../]?t=mkdir&name=NAME, but the new directory will
624 be populated with initial children via the POST request body. This command
625 will create additional intermediate mutable directories as necessary.
627 This accepts a format= argument in the query string, which controls the
628 format of the target directory, if the target directory is created as part
629 of the operation. format= is interpreted in the same way as in the POST/
630 uri?t=mkdir-with-children operation. Note that format= only controls the
631 format of the named target directory; intermediate directories, if created,
632 are created using the default mutable type setting, as configured on the
633 Tahoe-LAFS server responding to the request.
635 This operation will return an error if a blocking file is present at any of
636 the parent names, preventing the server from creating the necessary parent
637 directory; or if it would require changing an immutable directory; or if
638 the immediate parent directory already has a a child named NAME.
640 Note that the name= argument must be passed as a queryarg, because the POST
641 request body is used for the initial children JSON.
643 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir-immutable&name=NAME``
645 Like /uri/$DIRCAP/[SUBDIRS../]?t=mkdir-with-children&name=NAME, but the
646 final directory will be deep-immutable. The children are specified as a
647 JSON dictionary in the POST request body. Again, the name= argument must be
648 passed as a queryarg.
650 In Tahoe 1.6 this operation creates intermediate mutable directories if
651 necessary, but that behaviour should not be relied on; see ticket #920.
653 This operation will return an error if the parent directory is immutable,
654 or already has a child named NAME.
657 Getting Information About A File Or Directory (as JSON)
658 -------------------------------------------------------
660 ``GET /uri/$FILECAP?t=json``
662 ``GET /uri/$DIRCAP?t=json``
664 ``GET /uri/$DIRCAP/[SUBDIRS../]SUBDIR?t=json``
666 ``GET /uri/$DIRCAP/[SUBDIRS../]FILENAME?t=json``
668 This returns a machine-parseable JSON-encoded description of the given
669 object. The JSON always contains a list, and the first element of the list is
670 always a flag that indicates whether the referenced object is a file or a
671 directory. If it is a capability to a file, then the information includes
672 file size and URI, like this::
674 GET /uri/$FILECAP?t=json :
678 "verify_uri": verify_uri,
684 If it is a capability to a directory followed by a path from that directory
685 to a file, then the information also includes metadata from the link to the
686 file in the parent directory, like this::
688 GET /uri/$DIRCAP/[SUBDIRS../]FILENAME?t=json
692 "verify_uri": verify_uri,
697 "ctime": 1202777696.7564139,
698 "mtime": 1202777696.7564139,
700 "linkcrtime": 1202777696.7564139,
701 "linkmotime": 1202777696.7564139
704 If it is a directory, then it includes information about the children of
705 this directory, as a mapping from child name to a set of data about the
706 child (the same data that would appear in a corresponding GET?t=json of the
707 child itself). The child entries also include metadata about each child,
708 including link-creation- and link-change- timestamps. The output looks like
711 GET /uri/$DIRCAP?t=json :
712 GET /uri/$DIRCAP/[SUBDIRS../]SUBDIR?t=json :
715 "rw_uri": read_write_uri,
716 "ro_uri": read_only_uri,
717 "verify_uri": verify_uri,
721 "foo.txt": [ "filenode", {
725 "ctime": 1202777696.7564139,
726 "mtime": 1202777696.7564139,
728 "linkcrtime": 1202777696.7564139,
729 "linkmotime": 1202777696.7564139
731 "subdir": [ "dirnode", {
735 "ctime": 1202778102.7589991,
736 "mtime": 1202778111.2160511,
738 "linkcrtime": 1202777696.7564139,
739 "linkmotime": 1202777696.7564139
743 In the above example, note how 'children' is a dictionary in which the keys
744 are child names and the values depend upon whether the child is a file or a
745 directory. The value is mostly the same as the JSON representation of the
746 child object (except that directories do not recurse -- the "children"
747 entry of the child is omitted, and the directory view includes the metadata
748 that is stored on the directory edge).
750 The rw_uri field will be present in the information about a directory
751 if and only if you have read-write access to that directory. The verify_uri
752 field will be present if and only if the object has a verify-cap
753 (non-distributed LIT files do not have verify-caps).
755 If the cap is of an unknown format, then the file size and verify_uri will
758 GET /uri/$UNKNOWNCAP?t=json :
761 "ro_uri": unknown_read_uri
764 GET /uri/$DIRCAP/[SUBDIRS../]UNKNOWNCHILDNAME?t=json :
767 "rw_uri": unknown_write_uri,
768 "ro_uri": unknown_read_uri,
771 "ctime": 1202777696.7564139,
772 "mtime": 1202777696.7564139,
774 "linkcrtime": 1202777696.7564139,
775 "linkmotime": 1202777696.7564139
778 As in the case of file nodes, the metadata will only be present when the
779 capability is to a directory followed by a path. The "mutable" field is also
780 not always present; when it is absent, the mutability of the object is not
786 The value of the 'tahoe':'linkmotime' key is updated whenever a link to a
787 child is set. The value of the 'tahoe':'linkcrtime' key is updated whenever
788 a link to a child is created -- i.e. when there was not previously a link
791 Note however, that if the edge in the Tahoe filesystem points to a mutable
792 file and the contents of that mutable file is changed, then the
793 'tahoe':'linkmotime' value on that edge will *not* be updated, since the
794 edge itself wasn't updated -- only the mutable file was.
796 The timestamps are represented as a number of seconds since the UNIX epoch
797 (1970-01-01 00:00:00 UTC), with leap seconds not being counted in the long
800 In Tahoe earlier than v1.4.0, 'mtime' and 'ctime' keys were populated
801 instead of the 'tahoe':'linkmotime' and 'tahoe':'linkcrtime' keys. Starting
802 in Tahoe v1.4.0, the 'linkmotime'/'linkcrtime' keys in the 'tahoe' sub-dict
803 are populated. However, prior to Tahoe v1.7beta, a bug caused the 'tahoe'
804 sub-dict to be deleted by web-API requests in which new metadata is
805 specified, and not to be added to existing child links that lack it.
807 From Tahoe v1.7.0 onward, the 'mtime' and 'ctime' fields are no longer
808 populated or updated (see ticket #924), except by "tahoe backup" as
809 explained below. For backward compatibility, when an existing link is
810 updated and 'tahoe':'linkcrtime' is not present in the previous metadata
811 but 'ctime' is, the old value of 'ctime' is used as the new value of
812 'tahoe':'linkcrtime'.
814 The reason we added the new fields in Tahoe v1.4.0 is that there is a
815 "set_children" API (described below) which you can use to overwrite the
816 values of the 'mtime'/'ctime' pair, and this API is used by the
817 "tahoe backup" command (in Tahoe v1.3.0 and later) to set the 'mtime' and
818 'ctime' values when backing up files from a local filesystem into the
819 Tahoe filesystem. As of Tahoe v1.4.0, the set_children API cannot be used
820 to set anything under the 'tahoe' key of the metadata dict -- if you
821 include 'tahoe' keys in your 'metadata' arguments then it will silently
824 Therefore, if the 'tahoe' sub-dict is present, you can rely on the
825 'linkcrtime' and 'linkmotime' values therein to have the semantics described
826 above. (This is assuming that only official Tahoe clients have been used to
827 write those links, and that their system clocks were set to what you expected
828 -- there is nothing preventing someone from editing their Tahoe client or
829 writing their own Tahoe client which would overwrite those values however
830 they like, and there is nothing to constrain their system clock from taking
833 When an edge is created or updated by "tahoe backup", the 'mtime' and
834 'ctime' keys on that edge are set as follows:
836 * 'mtime' is set to the timestamp read from the local filesystem for the
837 "mtime" of the local file in question, which means the last time the
838 contents of that file were changed.
840 * On Windows, 'ctime' is set to the creation timestamp for the file
841 read from the local filesystem. On other platforms, 'ctime' is set to
842 the UNIX "ctime" of the local file, which means the last time that
843 either the contents or the metadata of the local file was changed.
845 There are several ways that the 'ctime' field could be confusing:
847 1. You might be confused about whether it reflects the time of the creation
848 of a link in the Tahoe filesystem (by a version of Tahoe < v1.7.0) or a
849 timestamp copied in by "tahoe backup" from a local filesystem.
851 2. You might be confused about whether it is a copy of the file creation
852 time (if "tahoe backup" was run on a Windows system) or of the last
853 contents-or-metadata change (if "tahoe backup" was run on a different
856 3. You might be confused by the fact that changing the contents of a
857 mutable file in Tahoe doesn't have any effect on any links pointing at
858 that file in any directories, although "tahoe backup" sets the link
859 'ctime'/'mtime' to reflect timestamps about the local file corresponding
860 to the Tahoe file to which the link points.
862 4. Also, quite apart from Tahoe, you might be confused about the meaning
863 of the "ctime" in UNIX local filesystems, which people sometimes think
864 means file creation time, but which actually means, in UNIX local
865 filesystems, the most recent time that the file contents or the file
866 metadata (such as owner, permission bits, extended attributes, etc.)
867 has changed. Note that although "ctime" does not mean file creation time
868 in UNIX, links created by a version of Tahoe prior to v1.7.0, and never
869 written by "tahoe backup", will have 'ctime' set to the link creation
873 Attaching an Existing File or Directory by its read- or write-cap
874 -----------------------------------------------------------------
876 ``PUT /uri/$DIRCAP/[SUBDIRS../]CHILDNAME?t=uri``
878 This attaches a child object (either a file or directory) to a specified
879 location in the virtual filesystem. The child object is referenced by its
880 read- or write- cap, as provided in the HTTP request body. This will create
881 intermediate directories as necessary.
883 This is similar to a UNIX hardlink: by referencing a previously-uploaded file
884 (or previously-created directory) instead of uploading/creating a new one,
885 you can create two references to the same object.
887 The read- or write- cap of the child is provided in the body of the HTTP
888 request, and this same cap is returned in the response body.
890 The default behavior is to overwrite any existing object at the same
891 location. To prevent this (and make the operation return an error instead
892 of overwriting), add a "replace=false" argument, as "?t=uri&replace=false".
893 With replace=false, this operation will return an HTTP 409 "Conflict" error
894 if there is already an object at the given location, rather than
895 overwriting the existing object. To allow the operation to overwrite a
896 file, but return an error when trying to overwrite a directory, use
897 "replace=only-files" (this behavior is closer to the traditional UNIX "mv"
898 command). Note that "true", "t", and "1" are all synonyms for "True", and
899 "false", "f", and "0" are synonyms for "False", and the parameter is
902 Note that this operation does not take its child cap in the form of
903 separate "rw_uri" and "ro_uri" fields. Therefore, it cannot accept a
904 child cap in a format unknown to the web-API server, unless its URI
905 starts with "ro." or "imm.". This restriction is necessary because the
906 server is not able to attenuate an unknown write cap to a read cap.
907 Unknown URIs starting with "ro." or "imm.", on the other hand, are
908 assumed to represent read caps. The client should not prefix a write
909 cap with "ro." or "imm." and pass it to this operation, since that
910 would result in granting the cap's write authority to holders of the
914 Adding Multiple Files or Directories to a Parent Directory at Once
915 ------------------------------------------------------------------
917 ``POST /uri/$DIRCAP/[SUBDIRS..]?t=set_children``
919 ``POST /uri/$DIRCAP/[SUBDIRS..]?t=set-children`` (Tahoe >= v1.6)
921 This command adds multiple children to a directory in a single operation.
922 It reads the request body and interprets it as a JSON-encoded description
923 of the child names and read/write-caps that should be added.
925 The body should be a JSON-encoded dictionary, in the same format as the
926 "children" value returned by the "GET /uri/$DIRCAP?t=json" operation
927 described above. In this format, each key is a child names, and the
928 corresponding value is a tuple of (type, childinfo). "type" is ignored, and
929 "childinfo" is a dictionary that contains "rw_uri", "ro_uri", and
930 "metadata" keys. You can take the output of "GET /uri/$DIRCAP1?t=json" and
931 use it as the input to "POST /uri/$DIRCAP2?t=set_children" to make DIR2
932 look very much like DIR1 (except for any existing children of DIR2 that
933 were not overwritten, and any existing "tahoe" metadata keys as described
936 When the set_children request contains a child name that already exists in
937 the target directory, this command defaults to overwriting that child with
938 the new value (both child cap and metadata, but if the JSON data does not
939 contain a "metadata" key, the old child's metadata is preserved). The
940 command takes a boolean "overwrite=" query argument to control this
941 behavior. If you use "?t=set_children&overwrite=false", then an attempt to
942 replace an existing child will instead cause an error.
944 Any "tahoe" key in the new child's "metadata" value is ignored. Any
945 existing "tahoe" metadata is preserved. The metadata["tahoe"] value is
946 reserved for metadata generated by the tahoe node itself. The only two keys
947 currently placed here are "linkcrtime" and "linkmotime". For details, see
948 the section above entitled "Get Information About A File Or Directory (as
949 JSON)", in the "About the metadata" subsection.
951 Note that this command was introduced with the name "set_children", which
952 uses an underscore rather than a hyphen as other multi-word command names
953 do. The variant with a hyphen is now accepted, but clients that desire
954 backward compatibility should continue to use "set_children".
957 Unlinking a File or Directory
958 -----------------------------
960 ``DELETE /uri/$DIRCAP/[SUBDIRS../]CHILDNAME``
962 This removes the given name from its parent directory. CHILDNAME is the
963 name to be removed, and $DIRCAP/SUBDIRS.. indicates the directory that will
966 Note that this does not actually delete the file or directory that the name
967 points to from the tahoe grid -- it only unlinks the named reference from
968 this directory. If there are other names in this directory or in other
969 directories that point to the resource, then it will remain accessible
970 through those paths. Even if all names pointing to this object are removed
971 from their parent directories, then someone with possession of its read-cap
972 can continue to access the object through that cap.
974 The object will only become completely unreachable once 1: there are no
975 reachable directories that reference it, and 2: nobody is holding a read-
976 or write- cap to the object. (This behavior is very similar to the way
977 hardlinks and anonymous files work in traditional UNIX filesystems).
979 This operation will not modify more than a single directory. Intermediate
980 directories which were implicitly created by PUT or POST methods will *not*
981 be automatically removed by DELETE.
983 This method returns the file- or directory- cap of the object that was just
987 Browser Operations: Human-oriented interfaces
988 =============================================
990 This section describes the HTTP operations that provide support for humans
991 running a web browser. Most of these operations use HTML forms that use POST
992 to drive the Tahoe node. This section is intended for HTML authors who want
993 to write web pages that contain forms and buttons which manipulate the Tahoe
996 Note that for all POST operations, the arguments listed can be provided
997 either as URL query arguments or as form body fields. URL query arguments are
998 separated from the main URL by "?", and from each other by "&". For example,
999 "POST /uri/$DIRCAP?t=upload&mutable=true". Form body fields are usually
1000 specified by using <input type="hidden"> elements. For clarity, the
1001 descriptions below display the most significant arguments as URL query args.
1004 Viewing A Directory (as HTML)
1005 -----------------------------
1007 ``GET /uri/$DIRCAP/[SUBDIRS../]``
1009 This returns an HTML page, intended to be displayed to a human by a web
1010 browser, which contains HREF links to all files and directories reachable
1011 from this directory. These HREF links do not have a t= argument, meaning
1012 that a human who follows them will get pages also meant for a human. It also
1013 contains forms to upload new files, and to unlink files and directories
1014 from their parent directory. Those forms use POST methods to do their job.
1017 Viewing/Downloading a File
1018 --------------------------
1020 ``GET /uri/$FILECAP``
1022 ``GET /uri/$DIRCAP/[SUBDIRS../]FILENAME``
1024 This will retrieve the contents of the given file. The HTTP response body
1025 will contain the sequence of bytes that make up the file.
1027 If you want the HTTP response to include a useful Content-Type header,
1028 either use the second form (which starts with a $DIRCAP), or add a
1029 "filename=foo" query argument, like "GET /uri/$FILECAP?filename=foo.jpg".
1030 The bare "GET /uri/$FILECAP" does not give the Tahoe node enough information
1031 to determine a Content-Type (since Tahoe immutable files are merely
1032 sequences of bytes, not typed+named file objects).
1034 If the URL has both filename= and "save=true" in the query arguments, then
1035 the server to add a "Content-Disposition: attachment" header, along with a
1036 filename= parameter. When a user clicks on such a link, most browsers will
1037 offer to let the user save the file instead of displaying it inline (indeed,
1038 most browsers will refuse to display it inline). "true", "t", "1", and other
1039 case-insensitive equivalents are all treated the same.
1041 Character-set handling in URLs and HTTP headers is a dubious art [1]_. For
1042 maximum compatibility, Tahoe simply copies the bytes from the filename=
1043 argument into the Content-Disposition header's filename= parameter, without
1044 trying to interpret them in any particular way.
1047 ``GET /named/$FILECAP/FILENAME``
1049 This is an alternate download form which makes it easier to get the correct
1050 filename. The Tahoe server will provide the contents of the given file, with
1051 a Content-Type header derived from the given filename. This form is used to
1052 get browsers to use the "Save Link As" feature correctly, and also helps
1053 command-line tools like "wget" and "curl" use the right filename. Note that
1054 this form can *only* be used with file caps; it is an error to use a
1055 directory cap after the /named/ prefix.
1058 Getting Information About A File Or Directory (as HTML)
1059 -------------------------------------------------------
1061 ``GET /uri/$FILECAP?t=info``
1063 ``GET /uri/$DIRCAP/?t=info``
1065 ``GET /uri/$DIRCAP/[SUBDIRS../]SUBDIR/?t=info``
1067 ``GET /uri/$DIRCAP/[SUBDIRS../]FILENAME?t=info``
1069 This returns a human-oriented HTML page with more detail about the selected
1070 file or directory object. This page contains the following items:
1074 * JSON representation
1075 * raw contents (text/plain)
1076 * access caps (URIs): verify-cap, read-cap, write-cap (for mutable objects)
1077 * check/verify/repair form
1078 * deep-check/deep-size/deep-stats/manifest (for directories)
1079 * replace-contents form (for mutable files)
1082 Creating a Directory
1083 --------------------
1085 ``POST /uri?t=mkdir``
1087 This creates a new empty directory, but does not attach it to the virtual
1090 If a "redirect_to_result=true" argument is provided, then the HTTP response
1091 will cause the web browser to be redirected to a /uri/$DIRCAP page that
1092 gives access to the newly-created directory. If you bookmark this page,
1093 you'll be able to get back to the directory again in the future. This is the
1094 recommended way to start working with a Tahoe server: create a new unlinked
1095 directory (using redirect_to_result=true), then bookmark the resulting
1096 /uri/$DIRCAP page. There is a "create directory" button on the Welcome page
1097 to invoke this action.
1099 This accepts a format= argument in the query string. Refer to the
1100 documentation of the PUT /uri?t=mkdir operation in `Creating A
1101 New Directory`_ for information on the behavior of the format= argument.
1103 If "redirect_to_result=true" is not provided (or is given a value of
1104 "false"), then the HTTP response body will simply be the write-cap of the
1107 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir&name=CHILDNAME``
1109 This creates a new empty directory as a child of the designated SUBDIR. This
1110 will create additional intermediate directories as necessary.
1112 This accepts a format= argument in the query string. Refer to the
1113 documentation of POST /uri/$DIRCAP/[SUBDIRS../]?t=mkdir&name=CHILDNAME in
1114 `Creating A New Directory`_ for information on the behavior of the format=
1117 If a "when_done=URL" argument is provided, the HTTP response will cause the
1118 web browser to redirect to the given URL. This provides a convenient way to
1119 return the browser to the directory that was just modified. Without a
1120 when_done= argument, the HTTP response will simply contain the write-cap of
1121 the directory that was just created.
1127 ``POST /uri?t=upload``
1129 This uploads a file, and produces a file-cap for the contents, but does not
1130 attach the file into the filesystem. No directories will be modified by
1133 The file must be provided as the "file" field of an HTML encoded form body,
1134 produced in response to an HTML form like this::
1136 <form action="/uri" method="POST" enctype="multipart/form-data">
1137 <input type="hidden" name="t" value="upload" />
1138 <input type="file" name="file" />
1139 <input type="submit" value="Upload Unlinked" />
1142 If a "when_done=URL" argument is provided, the response body will cause the
1143 browser to redirect to the given URL. If the when_done= URL has the string
1144 "%(uri)s" in it, that string will be replaced by a URL-escaped form of the
1145 newly created file-cap. (Note that without this substitution, there is no
1146 way to access the file that was just uploaded).
1148 The default (in the absence of when_done=) is to return an HTML page that
1149 describes the results of the upload. This page will contain information
1150 about which storage servers were used for the upload, how long each
1151 operation took, etc.
1153 This accepts format= and mutable=true query string arguments. Refer to
1154 `Writing/Uploading A File`_ for information on the behavior of format= and
1157 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=upload``
1159 This uploads a file, and attaches it as a new child of the given directory,
1160 which must be mutable. The file must be provided as the "file" field of an
1161 HTML-encoded form body, produced in response to an HTML form like this::
1163 <form action="." method="POST" enctype="multipart/form-data">
1164 <input type="hidden" name="t" value="upload" />
1165 <input type="file" name="file" />
1166 <input type="submit" value="Upload" />
1169 A "name=" argument can be provided to specify the new child's name,
1170 otherwise it will be taken from the "filename" field of the upload form
1171 (most web browsers will copy the last component of the original file's
1172 pathname into this field). To avoid confusion, name= is not allowed to
1175 If there is already a child with that name, and it is a mutable file, then
1176 its contents are replaced with the data being uploaded. If it is not a
1177 mutable file, the default behavior is to remove the existing child before
1178 creating a new one. To prevent this (and make the operation return an error
1179 instead of overwriting the old child), add a "replace=false" argument, as
1180 "?t=upload&replace=false". With replace=false, this operation will return an
1181 HTTP 409 "Conflict" error if there is already an object at the given
1182 location, rather than overwriting the existing object. Note that "true",
1183 "t", and "1" are all synonyms for "True", and "false", "f", and "0" are
1184 synonyms for "False". the parameter is case-insensitive.
1186 This will create additional intermediate directories as necessary, although
1187 since it is expected to be triggered by a form that was retrieved by "GET
1188 /uri/$DIRCAP/[SUBDIRS../]", it is likely that the parent directory will
1191 This accepts format= and mutable=true query string arguments. Refer to
1192 `Writing/Uploading A File`_ for information on the behavior of format= and
1195 If a "when_done=URL" argument is provided, the HTTP response will cause the
1196 web browser to redirect to the given URL. This provides a convenient way to
1197 return the browser to the directory that was just modified. Without a
1198 when_done= argument, the HTTP response will simply contain the file-cap of
1199 the file that was just uploaded (a write-cap for mutable files, or a
1200 read-cap for immutable files).
1202 ``POST /uri/$DIRCAP/[SUBDIRS../]FILENAME?t=upload``
1204 This also uploads a file and attaches it as a new child of the given
1205 directory, which must be mutable. It is a slight variant of the previous
1206 operation, as the URL refers to the target file rather than the parent
1207 directory. It is otherwise identical: this accepts mutable= and when_done=
1210 ``POST /uri/$FILECAP?t=upload``
1212 This modifies the contents of an existing mutable file in-place. An error is
1213 signalled if $FILECAP does not refer to a mutable file. It behaves just like
1214 the "PUT /uri/$FILECAP" form, but uses a POST for the benefit of HTML forms
1218 Attaching An Existing File Or Directory (by URI)
1219 ------------------------------------------------
1221 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=uri&name=CHILDNAME&uri=CHILDCAP``
1223 This attaches a given read- or write- cap "CHILDCAP" to the designated
1224 directory, with a specified child name. This behaves much like the PUT t=uri
1225 operation, and is a lot like a UNIX hardlink. It is subject to the same
1226 restrictions as that operation on the use of cap formats unknown to the
1229 This will create additional intermediate directories as necessary, although
1230 since it is expected to be triggered by a form that was retrieved by "GET
1231 /uri/$DIRCAP/[SUBDIRS../]", it is likely that the parent directory will
1234 This accepts the same replace= argument as POST t=upload.
1240 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=delete&name=CHILDNAME``
1242 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=unlink&name=CHILDNAME``
1244 This instructs the node to remove a child object (file or subdirectory) from
1245 the given directory, which must be mutable. Note that the entire subtree is
1246 unlinked from the parent. Unlike deleting a subdirectory in a UNIX local
1247 filesystem, the subtree need not be empty; if it isn't, then other references
1248 into the subtree will see that the child subdirectories are not modified by
1249 this operation. Only the link from the given directory to its child is severed.
1251 In Tahoe-LAFS v1.9.0 and later, t=unlink can be used as a synonym for t=delete.
1252 If interoperability with older web-API servers is required, t=delete should
1259 ``POST /uri/$DIRCAP/[SUBDIRS../]?t=rename&from_name=OLD&to_name=NEW``
1261 This instructs the node to rename a child of the given directory, which must
1262 be mutable. This has a similar effect to removing the child, then adding the
1263 same child-cap under the new name, except that it preserves metadata. This
1264 operation cannot move the child to a different directory.
1266 This operation will replace any existing child of the new name, making it
1267 behave like the UNIX "``mv -f``" command.
1272 ``GET /uri?uri=$CAP``
1274 This causes a redirect to /uri/$CAP, and retains any additional query
1275 arguments (like filename= or save=). This is for the convenience of web
1276 forms which allow the user to paste in a read- or write- cap (obtained
1277 through some out-of-band channel, like IM or email).
1279 Note that this form merely redirects to the specific file or directory
1280 indicated by the $CAP: unlike the GET /uri/$DIRCAP form, you cannot
1281 traverse to children by appending additional path segments to the URL.
1283 ``GET /uri/$DIRCAP/[SUBDIRS../]?t=rename-form&name=$CHILDNAME``
1285 This provides a useful facility to browser-based user interfaces. It
1286 returns a page containing a form targetting the "POST $DIRCAP t=rename"
1287 functionality described above, with the provided $CHILDNAME present in the
1288 'from_name' field of that form. I.e. this presents a form offering to
1289 rename $CHILDNAME, requesting the new name, and submitting POST rename.
1291 ``GET /uri/$DIRCAP/[SUBDIRS../]CHILDNAME?t=uri``
1293 This returns the file- or directory- cap for the specified object.
1295 ``GET /uri/$DIRCAP/[SUBDIRS../]CHILDNAME?t=readonly-uri``
1297 This returns a read-only file- or directory- cap for the specified object.
1298 If the object is an immutable file, this will return the same value as
1302 Debugging and Testing Features
1303 ------------------------------
1305 These URLs are less-likely to be helpful to the casual Tahoe user, and are
1306 mainly intended for developers.
1308 ``POST $URL?t=check``
1310 This triggers the FileChecker to determine the current "health" of the
1311 given file or directory, by counting how many shares are available. The
1312 page that is returned will display the results. This can be used as a "show
1313 me detailed information about this file" page.
1315 If a verify=true argument is provided, the node will perform a more
1316 intensive check, downloading and verifying every single bit of every share.
1318 If an add-lease=true argument is provided, the node will also add (or
1319 renew) a lease to every share it encounters. Each lease will keep the share
1320 alive for a certain period of time (one month by default). Once the last
1321 lease expires or is explicitly cancelled, the storage server is allowed to
1324 If an output=JSON argument is provided, the response will be
1325 machine-readable JSON instead of human-oriented HTML. The data is a
1326 dictionary with the following keys::
1328 storage-index: a base32-encoded string with the objects's storage index,
1329 or an empty string for LIT files
1330 summary: a string, with a one-line summary of the stats of the file
1331 results: a dictionary that describes the state of the file. For LIT files,
1332 this dictionary has only the 'healthy' key, which will always be
1333 True. For distributed files, this dictionary has the following
1335 count-shares-good: the number of good shares that were found
1336 count-shares-needed: 'k', the number of shares required for recovery
1337 count-shares-expected: 'N', the number of total shares generated
1338 count-good-share-hosts: this was intended to be the number of distinct
1339 storage servers with good shares. It is currently
1340 (as of Tahoe-LAFS v1.8.0) computed incorrectly;
1342 count-wrong-shares: for mutable files, the number of shares for
1343 versions other than the 'best' one (highest
1344 sequence number, highest roothash). These are
1346 count-recoverable-versions: for mutable files, the number of
1347 recoverable versions of the file. For
1348 a healthy file, this will equal 1.
1349 count-unrecoverable-versions: for mutable files, the number of
1350 unrecoverable versions of the file.
1351 For a healthy file, this will be 0.
1352 count-corrupt-shares: the number of shares with integrity failures
1353 list-corrupt-shares: a list of "share locators", one for each share
1354 that was found to be corrupt. Each share locator
1355 is a list of (serverid, storage_index, sharenum).
1356 needs-rebalancing: (bool) True if there are multiple shares on a single
1357 storage server, indicating a reduction in reliability
1358 that could be resolved by moving shares to new
1360 servers-responding: list of base32-encoded storage server identifiers,
1361 one for each server which responded to the share
1363 healthy: (bool) True if the file is completely healthy, False otherwise.
1364 Healthy files have at least N good shares. Overlapping shares
1365 do not currently cause a file to be marked unhealthy. If there
1366 are at least N good shares, then corrupt shares do not cause the
1367 file to be marked unhealthy, although the corrupt shares will be
1368 listed in the results (list-corrupt-shares) and should be manually
1369 removed to wasting time in subsequent downloads (as the
1370 downloader rediscovers the corruption and uses alternate shares).
1371 Future compatibility: the meaning of this field may change to
1372 reflect whether the servers-of-happiness criterion is met
1374 sharemap: dict mapping share identifier to list of serverids
1375 (base32-encoded strings). This indicates which servers are
1376 holding which shares. For immutable files, the shareid is
1377 an integer (the share number, from 0 to N-1). For
1378 immutable files, it is a string of the form
1379 'seq%d-%s-sh%d', containing the sequence number, the
1380 roothash, and the share number.
1382 ``POST $URL?t=start-deep-check`` (must add &ophandle=XYZ)
1384 This initiates a recursive walk of all files and directories reachable from
1385 the target, performing a check on each one just like t=check. The result
1386 page will contain a summary of the results, including details on any
1387 file/directory that was not fully healthy.
1389 t=start-deep-check can only be invoked on a directory. An error (400
1390 BAD_REQUEST) will be signalled if it is invoked on a file. The recursive
1391 walker will deal with loops safely.
1393 This accepts the same verify= and add-lease= arguments as t=check.
1395 Since this operation can take a long time (perhaps a second per object),
1396 the ophandle= argument is required (see "Slow Operations, Progress, and
1397 Cancelling" above). The response to this POST will be a redirect to the
1398 corresponding /operations/$HANDLE page (with output=HTML or output=JSON to
1399 match the output= argument given to the POST). The deep-check operation
1400 will continue to run in the background, and the /operations page should be
1401 used to find out when the operation is done.
1403 Detailed check results for non-healthy files and directories will be
1404 available under /operations/$HANDLE/$STORAGEINDEX, and the HTML status will
1405 contain links to these detailed results.
1407 The HTML /operations/$HANDLE page for incomplete operations will contain a
1408 meta-refresh tag, set to 60 seconds, so that a browser which uses
1409 deep-check will automatically poll until the operation has completed.
1411 The JSON page (/options/$HANDLE?output=JSON) will contain a
1412 machine-readable JSON dictionary with the following keys::
1414 finished: a boolean, True if the operation is complete, else False. Some
1415 of the remaining keys may not be present until the operation
1417 root-storage-index: a base32-encoded string with the storage index of the
1418 starting point of the deep-check operation
1419 count-objects-checked: count of how many objects were checked. Note that
1420 non-distributed objects (i.e. small immutable LIT
1421 files) are not checked, since for these objects,
1422 the data is contained entirely in the URI.
1423 count-objects-healthy: how many of those objects were completely healthy
1424 count-objects-unhealthy: how many were damaged in some way
1425 count-corrupt-shares: how many shares were found to have corruption,
1426 summed over all objects examined
1427 list-corrupt-shares: a list of "share identifiers", one for each share
1428 that was found to be corrupt. Each share identifier
1429 is a list of (serverid, storage_index, sharenum).
1430 list-unhealthy-files: a list of (pathname, check-results) tuples, for
1431 each file that was not fully healthy. 'pathname' is
1432 a list of strings (which can be joined by "/"
1433 characters to turn it into a single string),
1434 relative to the directory on which deep-check was
1435 invoked. The 'check-results' field is the same as
1436 that returned by t=check&output=JSON, described
1438 stats: a dictionary with the same keys as the t=start-deep-stats command
1441 ``POST $URL?t=stream-deep-check``
1443 This initiates a recursive walk of all files and directories reachable from
1444 the target, performing a check on each one just like t=check. For each
1445 unique object (duplicates are skipped), a single line of JSON is emitted to
1446 the HTTP response channel (or an error indication, see below). When the walk
1447 is complete, a final line of JSON is emitted which contains the accumulated
1448 file-size/count "deep-stats" data.
1450 This command takes the same arguments as t=start-deep-check.
1452 A CLI tool can split the response stream on newlines into "response units",
1453 and parse each response unit as JSON. Each such parsed unit will be a
1454 dictionary, and will contain at least the "type" key: a string, one of
1455 "file", "directory", or "stats".
1457 For all units that have a type of "file" or "directory", the dictionary will
1458 contain the following keys::
1460 "path": a list of strings, with the path that is traversed to reach the
1462 "cap": a write-cap URI for the file or directory, if available, else a
1464 "verifycap": a verify-cap URI for the file or directory
1465 "repaircap": an URI for the weakest cap that can still be used to repair
1467 "storage-index": a base32 storage index for the object
1468 "check-results": a copy of the dictionary which would be returned by
1469 t=check&output=json, with three top-level keys:
1470 "storage-index", "summary", and "results", and a variety
1471 of counts and sharemaps in the "results" value.
1473 Note that non-distributed files (i.e. LIT files) will have values of None
1474 for verifycap, repaircap, and storage-index, since these files can neither
1475 be verified nor repaired, and are not stored on the storage servers.
1476 Likewise the check-results dictionary will be limited: an empty string for
1477 storage-index, and a results dictionary with only the "healthy" key.
1479 The last unit in the stream will have a type of "stats", and will contain
1480 the keys described in the "start-deep-stats" operation, below.
1482 If any errors occur during the traversal (specifically if a directory is
1483 unrecoverable, such that further traversal is not possible), an error
1484 indication is written to the response body, instead of the usual line of
1485 JSON. This error indication line will begin with the string "ERROR:" (in all
1486 caps), and contain a summary of the error on the rest of the line. The
1487 remaining lines of the response body will be a python exception. The client
1488 application should look for the ERROR: and stop processing JSON as soon as
1489 it is seen. Note that neither a file being unrecoverable nor a directory
1490 merely being unhealthy will cause traversal to stop. The line just before
1491 the ERROR: will describe the directory that was untraversable, since the
1492 unit is emitted to the HTTP response body before the child is traversed.
1495 ``POST $URL?t=check&repair=true``
1497 This performs a health check of the given file or directory, and if the
1498 checker determines that the object is not healthy (some shares are missing
1499 or corrupted), it will perform a "repair". During repair, any missing
1500 shares will be regenerated and uploaded to new servers.
1502 This accepts the same verify=true and add-lease= arguments as t=check. When
1503 an output=JSON argument is provided, the machine-readable JSON response
1504 will contain the following keys::
1506 storage-index: a base32-encoded string with the objects's storage index,
1507 or an empty string for LIT files
1508 repair-attempted: (bool) True if repair was attempted
1509 repair-successful: (bool) True if repair was attempted and the file was
1510 fully healthy afterwards. False if no repair was
1511 attempted, or if a repair attempt failed.
1512 pre-repair-results: a dictionary that describes the state of the file
1513 before any repair was performed. This contains exactly
1514 the same keys as the 'results' value of the t=check
1515 response, described above.
1516 post-repair-results: a dictionary that describes the state of the file
1517 after any repair was performed. If no repair was
1518 performed, post-repair-results and pre-repair-results
1519 will be the same. This contains exactly the same keys
1520 as the 'results' value of the t=check response,
1523 ``POST $URL?t=start-deep-check&repair=true`` (must add &ophandle=XYZ)
1525 This triggers a recursive walk of all files and directories, performing a
1526 t=check&repair=true on each one.
1528 Like t=start-deep-check without the repair= argument, this can only be
1529 invoked on a directory. An error (400 BAD_REQUEST) will be signalled if it
1530 is invoked on a file. The recursive walker will deal with loops safely.
1532 This accepts the same verify= and add-lease= arguments as
1533 t=start-deep-check. It uses the same ophandle= mechanism as
1534 start-deep-check. When an output=JSON argument is provided, the response
1535 will contain the following keys::
1537 finished: (bool) True if the operation has completed, else False
1538 root-storage-index: a base32-encoded string with the storage index of the
1539 starting point of the deep-check operation
1540 count-objects-checked: count of how many objects were checked
1542 count-objects-healthy-pre-repair: how many of those objects were completely
1543 healthy, before any repair
1544 count-objects-unhealthy-pre-repair: how many were damaged in some way
1545 count-objects-healthy-post-repair: how many of those objects were completely
1546 healthy, after any repair
1547 count-objects-unhealthy-post-repair: how many were damaged in some way
1549 count-repairs-attempted: repairs were attempted on this many objects.
1550 count-repairs-successful: how many repairs resulted in healthy objects
1551 count-repairs-unsuccessful: how many repairs resulted did not results in
1552 completely healthy objects
1553 count-corrupt-shares-pre-repair: how many shares were found to have
1554 corruption, summed over all objects
1555 examined, before any repair
1556 count-corrupt-shares-post-repair: how many shares were found to have
1557 corruption, summed over all objects
1558 examined, after any repair
1559 list-corrupt-shares: a list of "share identifiers", one for each share
1560 that was found to be corrupt (before any repair).
1561 Each share identifier is a list of (serverid,
1562 storage_index, sharenum).
1563 list-remaining-corrupt-shares: like list-corrupt-shares, but mutable shares
1564 that were successfully repaired are not
1565 included. These are shares that need
1566 manual processing. Since immutable shares
1567 cannot be modified by clients, all corruption
1568 in immutable shares will be listed here.
1569 list-unhealthy-files: a list of (pathname, check-results) tuples, for
1570 each file that was not fully healthy. 'pathname' is
1571 relative to the directory on which deep-check was
1572 invoked. The 'check-results' field is the same as
1573 that returned by t=check&repair=true&output=JSON,
1575 stats: a dictionary with the same keys as the t=start-deep-stats command
1578 ``POST $URL?t=stream-deep-check&repair=true``
1580 This triggers a recursive walk of all files and directories, performing a
1581 t=check&repair=true on each one. For each unique object (duplicates are
1582 skipped), a single line of JSON is emitted to the HTTP response channel (or
1583 an error indication). When the walk is complete, a final line of JSON is
1584 emitted which contains the accumulated file-size/count "deep-stats" data.
1586 This emits the same data as t=stream-deep-check (without the repair=true),
1587 except that the "check-results" field is replaced with a
1588 "check-and-repair-results" field, which contains the keys returned by
1589 t=check&repair=true&output=json (i.e. repair-attempted, repair-successful,
1590 pre-repair-results, and post-repair-results). The output does not contain
1591 the summary dictionary that is provied by t=start-deep-check&repair=true
1592 (the one with count-objects-checked and list-unhealthy-files), since the
1593 receiving client is expected to calculate those values itself from the
1594 stream of per-object check-and-repair-results.
1596 Note that the "ERROR:" indication will only be emitted if traversal stops,
1597 which will only occur if an unrecoverable directory is encountered. If a
1598 file or directory repair fails, the traversal will continue, and the repair
1599 failure will be indicated in the JSON data (in the "repair-successful" key).
1601 ``POST $DIRURL?t=start-manifest`` (must add &ophandle=XYZ)
1603 This operation generates a "manfest" of the given directory tree, mostly
1604 for debugging. This is a table of (path, filecap/dircap), for every object
1605 reachable from the starting directory. The path will be slash-joined, and
1606 the filecap/dircap will contain a link to the object in question. This page
1607 gives immediate access to every object in the virtual filesystem subtree.
1609 This operation uses the same ophandle= mechanism as deep-check. The
1610 corresponding /operations/$HANDLE page has three different forms. The
1611 default is output=HTML.
1613 If output=text is added to the query args, the results will be a text/plain
1614 list. The first line is special: it is either "finished: yes" or "finished:
1615 no"; if the operation is not finished, you must periodically reload the
1616 page until it completes. The rest of the results are a plaintext list, with
1617 one file/dir per line, slash-separated, with the filecap/dircap separated
1620 If output=JSON is added to the queryargs, then the results will be a
1621 JSON-formatted dictionary with six keys. Note that because large directory
1622 structures can result in very large JSON results, the full results will not
1623 be available until the operation is complete (i.e. until output["finished"]
1626 finished (bool): if False then you must reload the page until True
1627 origin_si (base32 str): the storage index of the starting point
1628 manifest: list of (path, cap) tuples, where path is a list of strings.
1629 verifycaps: list of (printable) verify cap strings
1630 storage-index: list of (base32) storage index strings
1631 stats: a dictionary with the same keys as the t=start-deep-stats command
1634 ``POST $DIRURL?t=start-deep-size`` (must add &ophandle=XYZ)
1636 This operation generates a number (in bytes) containing the sum of the
1637 filesize of all directories and immutable files reachable from the given
1638 directory. This is a rough lower bound of the total space consumed by this
1639 subtree. It does not include space consumed by mutable files, nor does it
1640 take expansion or encoding overhead into account. Later versions of the
1641 code may improve this estimate upwards.
1643 The /operations/$HANDLE status output consists of two lines of text::
1648 ``POST $DIRURL?t=start-deep-stats`` (must add &ophandle=XYZ)
1650 This operation performs a recursive walk of all files and directories
1651 reachable from the given directory, and generates a collection of
1652 statistics about those objects.
1654 The result (obtained from the /operations/$OPHANDLE page) is a
1655 JSON-serialized dictionary with the following keys (note that some of these
1656 keys may be missing until 'finished' is True)::
1658 finished: (bool) True if the operation has finished, else False
1659 count-immutable-files: count of how many CHK files are in the set
1660 count-mutable-files: same, for mutable files (does not include directories)
1661 count-literal-files: same, for LIT files (data contained inside the URI)
1662 count-files: sum of the above three
1663 count-directories: count of directories
1664 count-unknown: count of unrecognized objects (perhaps from the future)
1665 size-immutable-files: total bytes for all CHK files in the set, =deep-size
1666 size-mutable-files (TODO): same, for current version of all mutable files
1667 size-literal-files: same, for LIT files
1668 size-directories: size of directories (includes size-literal-files)
1669 size-files-histogram: list of (minsize, maxsize, count) buckets,
1670 with a histogram of filesizes, 5dB/bucket,
1671 for both literal and immutable files
1672 largest-directory: number of children in the largest directory
1673 largest-immutable-file: number of bytes in the largest CHK file
1675 size-mutable-files is not implemented, because it would require extra
1676 queries to each mutable file to get their size. This may be implemented in
1679 Assuming no sharing, the basic space consumed by a single root directory is
1680 the sum of size-immutable-files, size-mutable-files, and size-directories.
1681 The actual disk space used by the shares is larger, because of the
1682 following sources of overhead::
1685 expansion due to erasure coding
1686 share management data (leases)
1687 backend (ext3) minimum block size
1689 ``POST $URL?t=stream-manifest``
1691 This operation performs a recursive walk of all files and directories
1692 reachable from the given starting point. For each such unique object
1693 (duplicates are skipped), a single line of JSON is emitted to the HTTP
1694 response channel (or an error indication, see below). When the walk is
1695 complete, a final line of JSON is emitted which contains the accumulated
1696 file-size/count "deep-stats" data.
1698 A CLI tool can split the response stream on newlines into "response units",
1699 and parse each response unit as JSON. Each such parsed unit will be a
1700 dictionary, and will contain at least the "type" key: a string, one of
1701 "file", "directory", or "stats".
1703 For all units that have a type of "file" or "directory", the dictionary will
1704 contain the following keys::
1706 "path": a list of strings, with the path that is traversed to reach the
1708 "cap": a write-cap URI for the file or directory, if available, else a
1710 "verifycap": a verify-cap URI for the file or directory
1711 "repaircap": an URI for the weakest cap that can still be used to repair
1713 "storage-index": a base32 storage index for the object
1715 Note that non-distributed files (i.e. LIT files) will have values of None
1716 for verifycap, repaircap, and storage-index, since these files can neither
1717 be verified nor repaired, and are not stored on the storage servers.
1719 The last unit in the stream will have a type of "stats", and will contain
1720 the keys described in the "start-deep-stats" operation, below.
1722 If any errors occur during the traversal (specifically if a directory is
1723 unrecoverable, such that further traversal is not possible), an error
1724 indication is written to the response body, instead of the usual line of
1725 JSON. This error indication line will begin with the string "ERROR:" (in all
1726 caps), and contain a summary of the error on the rest of the line. The
1727 remaining lines of the response body will be a python exception. The client
1728 application should look for the ERROR: and stop processing JSON as soon as
1729 it is seen. The line just before the ERROR: will describe the directory that
1730 was untraversable, since the manifest entry is emitted to the HTTP response
1731 body before the child is traversed.
1737 The portion of the web namespace that begins with "/uri" (and "/named") is
1738 dedicated to giving users (both humans and programs) access to the Tahoe
1739 virtual filesystem. The rest of the namespace provides status information
1740 about the state of the Tahoe node.
1742 ``GET /`` (the root page)
1744 This is the "Welcome Page", and contains a few distinct sections::
1746 Node information: library versions, local nodeid, services being provided.
1748 Filesystem Access Forms: create a new directory, view a file/directory by
1749 URI, upload a file (unlinked), download a file by
1752 Grid Status: introducer information, helper information, connected storage
1757 This page lists all active uploads and downloads, and contains a short list
1758 of recent upload/download operations. Each operation has a link to a page
1759 that describes file sizes, servers that were involved, and the time consumed
1760 in each phase of the operation.
1762 A GET of /status/?t=json will contain a machine-readable subset of the same
1763 data. It returns a JSON-encoded dictionary. The only key defined at this
1764 time is "active", with a value that is a list of operation dictionaries, one
1765 for each active operation. Once an operation is completed, it will no longer
1766 appear in data["active"] .
1768 Each op-dict contains a "type" key, one of "upload", "download",
1769 "mapupdate", "publish", or "retrieve" (the first two are for immutable
1770 files, while the latter three are for mutable files and directories).
1772 The "upload" op-dict will contain the following keys::
1774 type (string): "upload"
1775 storage-index-string (string): a base32-encoded storage index
1776 total-size (int): total size of the file
1777 status (string): current status of the operation
1778 progress-hash (float): 1.0 when the file has been hashed
1779 progress-ciphertext (float): 1.0 when the file has been encrypted.
1780 progress-encode-push (float): 1.0 when the file has been encoded and
1781 pushed to the storage servers. For helper
1782 uploads, the ciphertext value climbs to 1.0
1783 first, then encoding starts. For unassisted
1784 uploads, ciphertext and encode-push progress
1785 will climb at the same pace.
1787 The "download" op-dict will contain the following keys::
1789 type (string): "download"
1790 storage-index-string (string): a base32-encoded storage index
1791 total-size (int): total size of the file
1792 status (string): current status of the operation
1793 progress (float): 1.0 when the file has been fully downloaded
1795 Front-ends which want to report progress information are advised to simply
1796 average together all the progress-* indicators. A slightly more accurate
1797 value can be found by ignoring the progress-hash value (since the current
1798 implementation hashes synchronously, so clients will probably never see
1799 progress-hash!=1.0).
1801 ``GET /provisioning/``
1803 This page provides a basic tool to predict the likely storage and bandwidth
1804 requirements of a large Tahoe grid. It provides forms to input things like
1805 total number of users, number of files per user, average file size, number
1806 of servers, expansion ratio, hard drive failure rate, etc. It then provides
1807 numbers like how many disks per server will be needed, how many read
1808 operations per second should be expected, and the likely MTBF for files in
1809 the grid. This information is very preliminary, and the model upon which it
1810 is based still needs a lot of work.
1812 ``GET /helper_status/``
1814 If the node is running a helper (i.e. if [helper]enabled is set to True in
1815 tahoe.cfg), then this page will provide a list of all the helper operations
1816 currently in progress. If "?t=json" is added to the URL, it will return a
1817 JSON-formatted list of helper statistics, which can then be used to produce
1818 graphs to indicate how busy the helper is.
1820 ``GET /statistics/``
1822 This page provides "node statistics", which are collected from a variety of
1825 load_monitor: every second, the node schedules a timer for one second in
1826 the future, then measures how late the subsequent callback
1827 is. The "load_average" is this tardiness, measured in
1828 seconds, averaged over the last minute. It is an indication
1829 of a busy node, one which is doing more work than can be
1830 completed in a timely fashion. The "max_load" value is the
1831 highest value that has been seen in the last 60 seconds.
1833 cpu_monitor: every minute, the node uses time.clock() to measure how much
1834 CPU time it has used, and it uses this value to produce
1835 1min/5min/15min moving averages. These values range from 0%
1836 (0.0) to 100% (1.0), and indicate what fraction of the CPU
1837 has been used by the Tahoe node. Not all operating systems
1838 provide meaningful data to time.clock(): they may report 100%
1839 CPU usage at all times.
1841 uploader: this counts how many immutable files (and bytes) have been
1842 uploaded since the node was started
1844 downloader: this counts how many immutable files have been downloaded
1845 since the node was started
1847 publishes: this counts how many mutable files (including directories) have
1848 been modified since the node was started
1850 retrieves: this counts how many mutable files (including directories) have
1851 been read since the node was started
1853 There are other statistics that are tracked by the node. The "raw stats"
1854 section shows a formatted dump of all of them.
1856 By adding "?t=json" to the URL, the node will return a JSON-formatted
1857 dictionary of stats values, which can be used by other tools to produce
1858 graphs of node behavior. The misc/munin/ directory in the source
1859 distribution provides some tools to produce these graphs.
1861 ``GET /`` (introducer status)
1863 For Introducer nodes, the welcome page displays information about both
1864 clients and servers which are connected to the introducer. Servers make
1865 "service announcements", and these are listed in a table. Clients will
1866 subscribe to hear about service announcements, and these subscriptions are
1867 listed in a separate table. Both tables contain information about what
1868 version of Tahoe is being run by the remote node, their advertised and
1869 outbound IP addresses, their nodeid and nickname, and how long they have
1872 By adding "?t=json" to the URL, the node will return a JSON-formatted
1873 dictionary of stats values, which can be used to produce graphs of connected
1874 clients over time. This dictionary has the following keys::
1876 ["subscription_summary"] : a dictionary mapping service name (like
1877 "storage") to an integer with the number of
1878 clients that have subscribed to hear about that
1880 ["announcement_summary"] : a dictionary mapping service name to an integer
1881 with the number of servers which are announcing
1883 ["announcement_distinct_hosts"] : a dictionary mapping service name to an
1884 integer which represents the number of
1885 distinct hosts that are providing that
1886 service. If two servers have announced
1887 FURLs which use the same hostnames (but
1888 different ports and tubids), they are
1889 considered to be on the same host.
1892 Static Files in /public_html
1893 ============================
1895 The web-API server will take any request for a URL that starts with /static
1896 and serve it from a configurable directory which defaults to
1897 $BASEDIR/public_html . This is configured by setting the "[node]web.static"
1898 value in $BASEDIR/tahoe.cfg . If this is left at the default value of
1899 "public_html", then http://localhost:3456/static/subdir/foo.html will be
1900 served with the contents of the file $BASEDIR/public_html/subdir/foo.html .
1902 This can be useful to serve a javascript application which provides a
1903 prettier front-end to the rest of the Tahoe web-API.
1906 Safety and Security Issues -- Names vs. URIs
1907 ============================================
1909 Summary: use explicit file- and dir- caps whenever possible, to reduce the
1910 potential for surprises when the filesystem structure is changed.
1912 Tahoe provides a mutable filesystem, but the ways that the filesystem can
1913 change are limited. The only thing that can change is that the mapping from
1914 child names to child objects that each directory contains can be changed by
1915 adding a new child name pointing to an object, removing an existing child name,
1916 or changing an existing child name to point to a different object.
1918 Obviously if you query Tahoe for information about the filesystem and then act
1919 to change the filesystem (such as by getting a listing of the contents of a
1920 directory and then adding a file to the directory), then the filesystem might
1921 have been changed after you queried it and before you acted upon it. However,
1922 if you use the URI instead of the pathname of an object when you act upon the
1923 object, then the only change that can happen is if the object is a directory
1924 then the set of child names it has might be different. If, on the other hand,
1925 you act upon the object using its pathname, then a different object might be in
1926 that place, which can result in more kinds of surprises.
1928 For example, suppose you are writing code which recursively downloads the
1929 contents of a directory. The first thing your code does is fetch the listing
1930 of the contents of the directory. For each child that it fetched, if that
1931 child is a file then it downloads the file, and if that child is a directory
1932 then it recurses into that directory. Now, if the download and the recurse
1933 actions are performed using the child's name, then the results might be
1934 wrong, because for example a child name that pointed to a sub-directory when
1935 you listed the directory might have been changed to point to a file (in which
1936 case your attempt to recurse into it would result in an error and the file
1937 would be skipped), or a child name that pointed to a file when you listed the
1938 directory might now point to a sub-directory (in which case your attempt to
1939 download the child would result in a file containing HTML text describing the
1942 If your recursive algorithm uses the uri of the child instead of the name of
1943 the child, then those kinds of mistakes just can't happen. Note that both the
1944 child's name and the child's URI are included in the results of listing the
1945 parent directory, so it isn't any harder to use the URI for this purpose.
1947 The read and write caps in a given directory node are separate URIs, and
1948 can't be assumed to point to the same object even if they were retrieved in
1949 the same operation (although the web-API server attempts to ensure this
1950 in most cases). If you need to rely on that property, you should explicitly
1951 verify it. More generally, you should not make assumptions about the
1952 internal consistency of the contents of mutable directories. As a result
1953 of the signatures on mutable object versions, it is guaranteed that a given
1954 version was written in a single update, but -- as in the case of a file --
1955 the contents may have been chosen by a malicious writer in a way that is
1956 designed to confuse applications that rely on their consistency.
1958 In general, use names if you want "whatever object (whether file or
1959 directory) is found by following this name (or sequence of names) when my
1960 request reaches the server". Use URIs if you want "this particular object".
1966 Tahoe uses both mutable and immutable files. Mutable files can be created
1967 explicitly by doing an upload with ?mutable=true added, or implicitly by
1968 creating a new directory (since a directory is just a special way to
1969 interpret a given mutable file).
1971 Mutable files suffer from the same consistency-vs-availability tradeoff that
1972 all distributed data storage systems face. It is not possible to
1973 simultaneously achieve perfect consistency and perfect availability in the
1974 face of network partitions (servers being unreachable or faulty).
1976 Tahoe tries to achieve a reasonable compromise, but there is a basic rule in
1977 place, known as the Prime Coordination Directive: "Don't Do That". What this
1978 means is that if write-access to a mutable file is available to several
1979 parties, then those parties are responsible for coordinating their activities
1980 to avoid multiple simultaneous updates. This could be achieved by having
1981 these parties talk to each other and using some sort of locking mechanism, or
1982 by serializing all changes through a single writer.
1984 The consequences of performing uncoordinated writes can vary. Some of the
1985 writers may lose their changes, as somebody else wins the race condition. In
1986 many cases the file will be left in an "unhealthy" state, meaning that there
1987 are not as many redundant shares as we would like (reducing the reliability
1988 of the file against server failures). In the worst case, the file can be left
1989 in such an unhealthy state that no version is recoverable, even the old ones.
1990 It is this small possibility of data loss that prompts us to issue the Prime
1991 Coordination Directive.
1993 Tahoe nodes implement internal serialization to make sure that a single Tahoe
1994 node cannot conflict with itself. For example, it is safe to issue two
1995 directory modification requests to a single tahoe node's web-API server at the
1996 same time, because the Tahoe node will internally delay one of them until
1997 after the other has finished being applied. (This feature was introduced in
1998 Tahoe-1.1; back with Tahoe-1.0 the web client was responsible for serializing
1999 web requests themselves).
2001 For more details, please see the "Consistency vs Availability" and "The Prime
2002 Coordination Directive" sections of `mutable.rst <../specifications/mutable.rst>`_.
2008 Gateway nodes may find it necessary to prohibit access to certain files. The
2009 web-API has a facility to block access to filecaps by their storage index,
2010 returning a 403 "Forbidden" error instead of the original file.
2012 This blacklist is recorded in $NODEDIR/access.blacklist, and contains one
2013 blocked file per line. Comment lines (starting with ``#``) are ignored. Each
2014 line consists of the storage-index (in the usual base32 format as displayed
2015 by the "More Info" page, or by the "tahoe debug dump-cap" command), followed
2016 by whitespace, followed by a reason string, which will be included in the 403
2017 error message. This could hold a URL to a page that explains why the file is
2018 blocked, for example.
2020 So for example, if you found a need to block access to a file with filecap
2021 ``URI:CHK:n7r3m6wmomelk4sep3kw5cvduq:os7ijw5c3maek7pg65e5254k2fzjflavtpejjyhshpsxuqzhcwwq:3:20:14861``,
2022 you could do the following::
2024 tahoe debug dump-cap URI:CHK:n7r3m6wmomelk4sep3kw5cvduq:os7ijw5c3maek7pg65e5254k2fzjflavtpejjyhshpsxuqzhcwwq:3:20:14861
2025 -> storage index: whpepioyrnff7orecjolvbudeu
2026 echo "whpepioyrnff7orecjolvbudeu my puppy told me to" >>$NODEDIR/access.blacklist
2027 tahoe restart $NODEDIR
2028 tahoe get URI:CHK:n7r3m6wmomelk4sep3kw5cvduq:os7ijw5c3maek7pg65e5254k2fzjflavtpejjyhshpsxuqzhcwwq:3:20:14861
2029 -> error, 403 Access Prohibited: my puppy told me to
2031 The ``access.blacklist`` file will be checked each time a file or directory
2032 is accessed: the file's ``mtime`` is used to decide whether it need to be
2033 reloaded. Therefore no node restart is necessary when creating the initial
2034 blacklist, nor when adding second, third, or additional entries to the list.
2035 When modifying the file, be careful to update it atomically, otherwise a
2036 request may arrive while the file is only halfway written, and the partial
2037 file may be incorrectly parsed.
2039 The blacklist is applied to all access paths (including FTP, SFTP, and CLI
2040 operations), not just the web-API. The blacklist also applies to directories.
2041 If a directory is blacklisted, the gateway will refuse access to both that
2042 directory and any child files/directories underneath it, when accessed via
2043 "DIRCAP/SUBDIR/FILENAME" -style URLs. Users who go directly to the child
2044 file/dir will bypass the blacklist.
2046 The node will log the SI of the file being blocked, and the reason code, into
2047 the ``logs/twistd.log`` file.
2050 .. [1] URLs and HTTP and UTF-8, Oh My
2052 HTTP does not provide a mechanism to specify the character set used to
2053 encode non-ASCII names in URLs
2054 (`RFC3986#2.1 <http://tools.ietf.org/html/rfc3986#section-2.1>`_).
2055 We prefer the convention that the ``filename=`` argument shall be a
2056 URL-escaped UTF-8 encoded Unicode string.
2057 For example, suppose we want to provoke the server into using a filename of
2058 "f i a n c e-acute e" (i.e. f i a n c U+00E9 e). The UTF-8 encoding of this
2059 is 0x66 0x69 0x61 0x6e 0x63 0xc3 0xa9 0x65 (or "fianc\\xC3\\xA9e", as python's
2060 ``repr()`` function would show). To encode this into a URL, the non-printable
2061 characters must be escaped with the urlencode ``%XX`` mechanism, giving
2062 us "fianc%C3%A9e". Thus, the first line of the HTTP request will be
2063 "``GET /uri/CAP...?save=true&filename=fianc%C3%A9e HTTP/1.1``". Not all
2064 browsers provide this: IE7 by default uses the Latin-1 encoding, which is
2065 "fianc%E9e" (although it has a configuration option to send URLs as UTF-8).
2067 The response header will need to indicate a non-ASCII filename. The actual
2068 mechanism to do this is not clear. For ASCII filenames, the response header
2071 Content-Disposition: attachment; filename="english.txt"
2073 If Tahoe were to enforce the UTF-8 convention, it would need to decode the
2074 URL argument into a Unicode string, and then encode it back into a sequence
2075 of bytes when creating the response header. One possibility would be to use
2076 unencoded UTF-8. Developers suggest that IE7 might accept this::
2078 #1: Content-Disposition: attachment; filename="fianc\xC3\xA9e"
2079 (note, the last four bytes of that line, not including the newline, are
2080 0xC3 0xA9 0x65 0x22)
2082 `RFC2231#4 <http://tools.ietf.org/html/rfc2231#section-4>`_
2083 (dated 1997): suggests that the following might work, and
2084 `some developers have reported <http://markmail.org/message/dsjyokgl7hv64ig3>`_
2085 that it is supported by Firefox (but not IE7)::
2087 #2: Content-Disposition: attachment; filename*=utf-8''fianc%C3%A9e
2089 My reading of `RFC2616#19.5.1 <http://tools.ietf.org/html/rfc2616#section-19.5.1>`_
2090 (which defines Content-Disposition) says that the filename= parameter is
2091 defined to be wrapped in quotes (presumably to allow spaces without breaking
2092 the parsing of subsequent parameters), which would give us::
2094 #3: Content-Disposition: attachment; filename*=utf-8''"fianc%C3%A9e"
2096 However this is contrary to the examples in the email thread listed above.
2098 Developers report that IE7 (when it is configured for UTF-8 URL encoding,
2099 which is not the default in Asian countries), will accept::
2101 #4: Content-Disposition: attachment; filename=fianc%C3%A9e
2103 However, for maximum compatibility, Tahoe simply copies bytes from the URL
2104 into the response header, rather than enforcing the UTF-8 convention. This
2105 means it does not try to decode the filename from the URL argument, nor does
2106 it encode the filename into the response header.