Hi.<br>I'm busy with work lately, but there's a discussion Zooko and I were having on a closed ticket, and I agree with him it actually belongs here, so here goes:<br><br>Sometimes there's a need to expose a [partial view of a] Tahoe-LAFS storage as a public web service. As far as I understand, there are 3 ways to do it.<br>
<br>1) Gateway to web api - the public server proxies requests to Tahoe's web api, blocking undesired requests (e.g. POST ones). This is what <a href="https://bitbucket.org/nejucomo/lafs-rpg">lafs-rpg</a> does (using nginx). You can also tweak it to in various ways (e.g. <a href="https://gist.github.com/4106919#file_nginx.txt">disable directory browsing</a> under some subtree). <br>
<br>2) Static web server, file-system back-end - use a standard static html web server (apache, nginx, etc.) and let it serve files from a <a href="https://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ#Q23_FUSE">fuse-mounted</a> Tahoe-LAFS cap. In the future, once we have "dropbox-like functionality", it would enable us to serve static files from a "magically synced" file-system folder, and we won't even need the fuse trickery.<br>
<br>3) Dedicated service - Tahoe-LAFS can have, in addition to the web api, a public web service (listening on a different port). We would need to define the various mountpoints this server has (e.g. map /blog/ to /uri/DIR-RO:.../Latest/), and additional configuration options (basic/other auth, mustache/jinja2/etc. template for directory browsing if allowed, etc.). We can either do all that explicitly at tahoe.cfg, or simply specifiy a capability where this config (probably json) is read from (handy if you want to remotely configure such a server, but might be vulnerable for exactly the same reason).<br>
<br>Option 1 is <a href="https://dubiousdod.org">what I use at the moment</a>. It may not be a pretty sight, but it ain't broke (AFAIK) so I don't have an urge to fix it.<br>Zooko prefers option 3. I agree this could be neat.<br>
What's <i>your</i> opinion?<br><br>Cheers,<br>The Dod<br>