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

[Ben Laurie]

Brian Warner wrote:
> 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)

What happened to /.../FILENAME?cap

> 
> 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
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
> 
> 


-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff