Serving files with booster-http
Configuring booster-http to serve blocks and files
Last updated
Configuring booster-http to serve blocks and files
Last updated
With the release v1.7.0-rc1 of booster-http, Storage Providers can now serve blocks and files directly over the HTTP protocol. booster-http
now implements a IPFS HTTP gateway with a path resolution style. This will allow the clients to download individual IPFS blocks, car files and request uploaded files directly from their browser.
SPs can take advantage of the ecosystem of tools to manage HTTP traffic, like load balancers and reverse proxies.
Before proceeding any further, we request you to read basics of HTTP retrieval configuration. This section is an extension of HTTP retrievals and deals with configuration specific to serving files and raw blocks.
The booster-http
service can be started with specific type of content on IPFS gateway API
This allows SPs to run multiple booster-http
instances, each serving specific type of content like car files only or raw blocks only.
In the curl request below we appended the query parameter format=raw to the URL to get the raw block data for the file.
But, if we try to open the file directly in a web browser, with no extra query parameters, we get an error message:
By default booster-http
does not serve files in a format that can be read by a web browser. This is to protect Storage Providers from serving content that may be flagged as illicit content.
To enable serving files to web browsers, we must pass --serve-files=true
to booster-http
on startup. Once, booster-http
is restarted with --serve-files=true,
we can open the file directly from a web browser:
booster-http
(and booster-bitswap
) automatically filter out known flagged content using the denylist maintained at https://badbits.dwebops.pub/denylist.json
We can also browse all files in the CAR archive.
SPs must secure their booster-http
before exposing it to the public. SPs can feel free to use any tool available to limit who can download files, the number of requests per second, and the download bandwidth each client can use per second.
Users can follow this example to use NGNIX reverse proxy to secure their booster-http
instance. In this section we’ve just scratched the surface of the ways in which nginx can set access limits, rate limits and bandwidth limits. In particular it’s possible to add limits by request token, or using JWT tokens. The examples in this section are adapted from Deploying NGINX as an API Gateway which goes into more detail.
By default nginx puts configuration files into /etc/nginx
The default configuration file is /etc/nginx/sites-available/default
Setup nginx server listen on port 7575
and forward requests to booster-http on port 7777
The IPFS gateway serves files from /ipfs
. So, we will add a server block for location /ipfs/
Let’s limit access to the IPFS gateway using the standard .htaccess
file. We need to set up an .htaccess
file with a username and password. Create a user named alice
Include the .htaccess
file in the /etc/nginx/sites-available/default
Now when we open any URL under the path /ipfs
we will be presented with a Sign in dialog.
To prevent users from making too many requests per second, we should add rate limits.
Create a file with the rate limiting configuration at /etc/nginx/ipfs-gateway.conf.d/ipfs-gateway.conf
Add a request zone limit to the file of 1 request per second, per client IP
Include ipfs-gateway.conf
in /etc/nginx/sites-available/default
and set the response for too many requests to HTTP response code 429
Click the refresh button in your browser on any path under /ipfs more than once per second you will see a 429 error page
It is also recommended to limit the amount of bandwidth that clients can take up when downloading data from booster-http
. This ensures a fair bandwidth distribution to each client and prevents situations where one client ends up choking the booster-http
instance.
Create a new .htaccess user called bob
Add a mapping from .htaccess
username to bandwidth limit in /etc/nginx/ipfs-gateway.conf.d/ipfs-gateway.conf
Add the bandwidth limit to /etc/nginx/sites-available/default
To verify bandwidth limiting, use curl
to download a file with user alice
and then bob
Note the difference in the Average Dload column (the average download speed).