Disable HTTP Range Requests on Synology WebStation, Apache or Nginx

I use my Synology NAS to host a variety of services including a web server, file server and a backup system. As part of some testing that I had been performing, I needed to ensure that my web server does not respond to HTTP Range Requests, which allow clients to retrieve specific byte ranges rather than downloading an entire resource in a single transfer.

We can check whether a web server supports HTTP Range Requests by specifying a range of bytes as demonstrated in this cURL example below:

curl -H "Range: bytes=0-10" -I http://depot.vcf.lab/PROD/vsan/hcl/lastupdatedtime.json -u $CREDS

You should receive an HTTP 206 response which indicates HTTP Range Requests is supported by your web server, which my Synology supports by default.

Unlike a traditional web server where disabling HTTP Range Requests is pretty straightforward, modifying the default behavior for Synology WebStation is slightly more complicated. After some trial and error, I was able to successfully disable HTTP Range Requests on my Synology system, and for those with a similar requirement, the following sections outline the steps for several popular web server backends.

Apache

Run sudo a2enmod and then add the following to your apache configuration and then restart apache.

Header unset Accept-Ranges
RequestHeader unset Range

Nginx

Add the following to your Nginx configuration and then restart Nginx.

max_ranges 0

Synology WebStation

Step 1 - Navigate to Package Center->Web Station->Web Portal and create a new Web Service Portal based on your desired configuration such as shown in the example below:

Step 2 - Navigate to Package Center->Web Station->Web Service and create a new Static Website to map the web service you had created to the desired document root and HTTP backend, which I am using Nginx.

Step 3 - SSH to your Synology and switch to the root user (or you can use sudo) and then cd into /usr/local/etc/nginx/sites-available directory. Depending on your setup, you may find a number of web portal configuration files and we need to identify the one that is mapped to ours that was created in Step 1. Since I choose a different HTTP port (8888), that would be one unique way to quickly search all files as that is the only service that is using that port on my Synology, which you can use the following command:

grep 8888 *

As you can see from the screenshot, our web portal configuration file is stored in ead24cle-18a1-4810-85b-9aab25d38383.w3conf 

Step 4 - We now need to view the contents of the file from Step 3 and look for the very last include statement, which in my example is /usr/local/etc/nginx/conf.d/.service.43e641d2-e92f-45d3-8590-801fb022ae26.91246eb8-1f73-4c40-a95b-cd1da6537dd1.conf

Step 5 - Finally, we can view the contents of this file to understand the full path to the user customization file (user.conf) as shown in the screenshot below.

We now have all the pieces of information to apply our custom configuration for your web service.

Step 6 - We need to create the directory before the user.conf which is the UUID shown in Step 5

mkdir -p /usr/local/etc/nginx/conf.d/91246eb8-1f73-4c40-a95b-cd1da6537dd1

Then we will create the /usr/local/etc/nginx/conf.d/91246eb8-1f73-4c40-a95b-cd1da6537dd1/user.conf that will contain your customization which should specify the desired location label within the root directory and the following for disabling HTTP range requests:

location /PROD/ {
    alias /volume1/web/PROD/;
    autoindex on;

    # Disable Byte-Range requests
    max_ranges 0;
    set $http_range "";
    add_header Accept-Ranges "none" always;

    # Performance
    gzip off;

    # Ensure Nginx looks for the file before giving up
    try_files $uri $uri/ =404;
}

Step 8 - Run the following command to verify that our configuration file is correct:

nginx -t

Step 9 - Run the following command to restart Nginx backend

synosystemctl restart nginx

Step 10 - If we now perform the same cURL operation against our new web service endpoint on port 8888:

curl -H "Range: bytes=0-10" -I http://depot.vcf.lab:8888/PROD/vsan/hcl/lastupdatedtime.json -u $CREDS

we can see that we no longer receive an HTTP 206 but just HTTP 200 response, which is verifies that the backend web server does not support an HTTP Range Requests anymore.