Whoops! Before, config files were being read but all the contents were basically
being discarded.
Now, we both load and actually use the config file, leading to a much more positive
experience for everyone involved :)
This is an example middleware which can be used as an AuthMiddleware for only
allowing requests to non-view pages which are accompanied by an auth token via
HTTP basic auth.
This allows clients to register an authentication middleware which will be
provided values in the context that it can use to make an authn/authz decision.
This previous behaviour was to, instead of hashing the file, just return the
first few bytes of it, which is neither intuitive nor the behaviour I was
looking for.
This ensures that we always have syntax highlighting available.
For people using it directly, it's their responsibility to make sure that
cheddar is available in their path, if they want syntax highlighting.
We might get bad requests for e.g. file uploads, so we should have an error
handler for that.
This also disables mime type sniffing for the other text/plain error handler.
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.
