We'll need this for cleanup operations as well. This should likely be factored
out again into an entirely separate package that deals with storage access.
We support several methods of serving assets:
* Redirect to blobstore
- This requires the backend to support signed URLs.
We rely on the backend to support HTTP semantics, like supporting
Range headers.
* Serve-using-http.ServeContent
- This requires the backend to actually be providing a io.ReadSeeker.
net/http provides Range/If- conditional support.
* Serve-proxy
- This is the safest and most compatible method.
We don't support conditionals nor Range headers. This mode is unlikely
to be suitable for multimedia, like MP3s or video.
This adds both redirect-to-signed-URL and proxy fileserving.
The proxy fileserving is somewhat limited: we don't support the Range header,
and it isn't easy to reuse the net/http ServeContent implementation because
that requires a SeekCloser. I think it might be possible to "bodge" a
SeekCloser on top of dynamically opening files, but it'll be a bit wonky and
will be slower than strictly necessary.
We add the hash of the file to the static assets, so they can be cached
indefinitely. This also, however, means that we need some way of referring to
them.
We need to depend on its API for fuphttp, so it's better if it's a separate
package to avoid embedding things we don't need.
In general it's probably a good idea to separate the logic from the embedded
content...
This allows setting the persistent storage location to save files into.
NOTE: defaults to mem:// for development purposes, which... is gonna be a bad
time.
This extracts the hash-named static assets into a directory. This is primarily
useful if you have multiple instances of fup running and you therefore need to
serve /static from a shared filesystem of some sort.
