In order to prevent viewing content, which max-download rate has been reached,
we need to ensure the data is not stored locally in a browser cache.
To achieve this, we set the Cache-Control Setting to "no-store" according to:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Controlfixes#470
* Add X-Url-Delete-* headers to POST handler
* Remove token from header
* Fix writing of headers
* Handle error returned by Write
* Update handlers.go
Co-authored-by: Andrea Spacca <andrea.spacca@gmail.com>
This change propagates the context of the actual user request through.
Additionally it configures the Storj Backend to do in memory buffering instead of relying on temporary files in /tmp/ folders.
Fixes#448
This change moves a couple of defers in order to prevent them from not being executed since we have returned in error cases early.
It also fixes a couple of smaller linting issues, like error messages not starting with a capital letter and variable name collisions with imported packages.
* issue #420 return 400 response when Max-Days is too big
* issue #420 moved the Max-Days check before saving the metadata
* issue #420 added a logging message when Max-Days is invalid
* issue #420 added MaxDate.IsZero() check
Co-authored-by: kugiyasan <kugiyasan@users.noreply.github.com>
For files that have no limit, there is no reason to track the download counter as its value will never be used anyway. This reduces costs on storage backends that have an operation fee (e.g. AWS S3) or a minimum retention (e.g. Wasabi S3).
Previously, the metadata file would be rewritten even if the download counter stayed the same (i.e. `increaseDownload = false`, previews and HEAD requests). Because the metadata doesn't change in that case, this would simply rewrite the exact same contents needlessly, which may also incur extra costs depending on the storage backend.
