id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
527	download: support Range header, in a quick hackish tempfile way	warner		"Currently, tahoe supports ""streaming download"", which really means we can serve the first byte of the response quickly (without needing to process the whole file; this is enabled by the use of merkle hash trees). But the real form of streaming download that we want is to support the HTTP ""Range"" header, which a client uses to tell the server that they only want a specific chunk of the target file, rather than the whole thing.

It turns out that the Quicktime media player in the iPhone depends upon this feature: it is unable to play music or movies that are served by a webserver which does not honor the Range header.

The long-term way to address this is by rewriting the download code to allow random-access (this will be done as a side-effect of the effort to make download tolerate stalled/slow servers). But we thought of a short-term approach this afternoon, which is worth doing sooner.

The Twisted web server code, in static.File, knows how to handle the Range header when it is serving a real file from local disk. So the idea is that:

 * if the Tahoe web code (specifically {{{web.filenode.FileDownloader}}}) sees a Range header in the request, it bypasses the usual producer/consumer {{{DownloadTarget}}} code
  * it looks in the cache directory to see if the file is already present there. The readcap is used as the cache file name.
   * if not, the file is downloaded into the cache. It must be downloaded into a tempfile first, and the code must avoid doing multiple downloads of the same file
  * once the file is present in the cache, the code returns a {{{static.File}}} resource for the target, enabling the Range header to be processed
 * if there is no Range header, we use the normal {{{DownloadTarget}}} and don't use a tempfile

Some manual process (i.e. a cronjob) would be responsible for deleting old files from the cache every once in a while.

The nice thing about this approach is that clients won't even notice when we get it fixed correctly and have proper random-access support. They'll just see a shorter turnaround time.
"	enhancement	closed	major	1.3.0	code-frontend-web	1.2.0	fixed	performance confidentiality