multiblob-http
serve content-addressed blobs over http. see use with multiblob
example
var MultiBlob = require('multiblob')
var MultiBlobHttp = require('multiblob-http')
var http = require('http')
var dir = where_files_go //set this.
var blobs = MultiBlob(dir)
http.createServer(MultiBlobHttp(blobs, '/blobs')).listen(8000)this will return an http handler (compatible with express middleware) that will handle requests
GET /blobs/get/{id}POST /blobs/add(which will respond with the hash)
you can also set a different prefix, but I use /blobs
http api
GET /get/{id}
retrive blob with hash {id}
range requests rfc 7233 are supported, This enables better video playback in browsers. Browsers tend to refuse to loop videos otherwise and seeking in videos requires range requests. It's also great for extracting embedded thumbnails from JPEGs etc.
POST /add
posts to add do not require to have a hash, but will respond with the hash. (TODO: take a POST to /add/{id} and error if received content did not have that hash)
caching && headers
multiblobs-http provides the correct headers to make serving content-addressed
files as efficient as possible.
First the the etag header is set to the hash and the expires header is set to a year in the future.
Ideally, the browser shouldn't request this resource again for a whole year.
Probably it might revalidate it when someone uses ctrl-R to reload the page.
When it does, it will request with if-none-modified set to the hash.
Since content-addressed files are never modified, the server immediately responds
with 304 (not modified)
the content-length header is always used unless "opts.size=false".
This way, if a connection fails somehow,
or there is an error later, the browser should detect it.
Of course, it would be way better if browsers just understood content-hashes.
But, we have to play the hand we where delt, and
multiblob-http makes the most of the broken web we live in.
License
MIT
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent