[tahoe-dev] help: how should you tell a web browser what name to use for a file?

[Brian Warner]

So, in an attempt to make progress on this one, here's a new summary of the
current proposals:

 1: /named/FILECAP/FILENAME
    (where "named" might be spelled differently)

 2: /cap/(FILECAP|DIRCAP+PATH)/$MAGIC/FILENAME
    2a: $MAGIC = "", rejected because "//" feels dubious
    2b: $MAGIC = "@@name="

 3: /cap/(FILECAP|DIRCAP+PATH)/FILENAME
    (i.e. any attempt to lookup a "child of a file" results in the same file)

If we go with #2, then whatever value we pick for $MAGIC must be removed from
the list of child names that you're allowed to use in your Tahoe directories,
and we need to document this fact. (I don't see how "escaping" the name would
work.. that implies that there are two different string types involved, and
then we have to document which API takes which type, which strikes me as more
challenging than documenting the fact that your users aren't allowed to use
$MAGIC as a file- or directory- name).

Note that at the moment, the only limitation on these names is that they are
a UTF-8 encoding of some valid unicode string. We might also require that
they do not contain a slash, but I'm not sure.. I think you could use %2F to
put a slash in one, which might be useful on platforms (windows? mac? VMS?
:-) that allow slashes in filenames because they use something else as a
delimiter.

I expect this trick (making sure that /FILENAME appears at the end of the
URL) to be used in two places:

  the human-oriented HTML directory browser (aka the "WUI"), as the HREF
  target of the left-most links that point to specific files, suitable for
  right-clicking and either doing "Save Link As" or pasting into some other
  tool like wget

  a fancier javascript-based frontend that has a need to give the user a URL
  from which they can download a specific file

I expect that programs (using the machine-oriented "WAPI", with ?t=json and
such) would not have much of a need for this feature, except when they want
to give a URL to a human to give to some other program like wget. Programs
are capable of deciding upon a filename for themselves.

I do not expect to ever see this trick used with the DIRCAP+PATH form, for
two reasons: first because any program or server which needs to create a
downloadable / right-clickable / wgettable URL for such an object can
determine the FILECAP itself and produce a URL that doesn't include the
DIRCAP (which is less authority anyways), and second because the DIRCAP+PATH
form already has the desired /FILENAME at the end of the URL (unless
?save=true has been added to it, and if a browser sees that it will honor the
filename in the Content-Disposition header).

So, examples of these URLs:

 #1: http://127.0.0.1:8123/named/URI%3ACHK%3Aime6pvkaxuetdfah2p2f35pe54%3A4btz54xk3tew6nd4y2ojpxj4m6wxjqqlwnztgre6gnjgtucd5r4a%3A3%3A10%3A202/welcome.txt

 #2a: http://127.0.0.1:8123/uri/URI%3ACHK%3Aime6pvkaxuetdfah2p2f35pe54%3A4btz54xk3tew6nd4y2ojpxj4m6wxjqqlwnztgre6gnjgtucd5r4a%3A3%3A10%3A202//welcome.txt

 #2b: http://127.0.0.1:8123/uri/URI%3ACHK%3Aime6pvkaxuetdfah2p2f35pe54%3A4btz54xk3tew6nd4y2ojpxj4m6wxjqqlwnztgre6gnjgtucd5r4a%3A3%3A10%3A202/@@name=/welcome.txt

 #3: http://127.0.0.1:8123/uri/URI%3ACHK%3Aime6pvkaxuetdfah2p2f35pe54%3A4btz54xk3tew6nd4y2ojpxj4m6wxjqqlwnztgre6gnjgtucd5r4a%3A3%3A10%3A202/welcome.txt


I'm still happy with #1, with something better than "named" as the prefix.

cheers,
 -Brian