Implementing URL rewrites at the edge allows you to serve Files.com Public Hosting content through your own domain without redirecting users or exposing the original hosted-by-files.com URLs. This page provides an overview of how to achieve that using several major edge platforms, including Cloudflare, Fastly, Akamai, AWS, Vercel, and Netlify. Each platform has its own method for rewriting requests, and we recommend reviewing the relevant provider documentation for configuration details and best practices.

CloudFlare Workers

Cloudflare Workers let you create URL rewrite rules that run at the edge, so you can redirect requests cleanly without exposing the underlying hosted-by-files.com URL. To serve your Publicly Hosted Folder from your own domain, such as example.com/resources, use a Worker to intercept requests and forward them to your Files.com-hosted content.

Here is how you can set this up using Cloudflare. Log in to your Cloudflare account and select the example.com domain. In Cloudflare’s left navigation, go to Workers & Pages and open the Manage Workers tab. Create a new Worker to launch a serverless function. Cloudflare provides an online editor with starter code, which you can replace with a custom script that rewrites the path and routes it to your Public Hosting URL on Files.com.

For example, if your Public Hosting folder is available at https://your-subdomain.hosted-by-files.com/resources/ and you want users to access it through https://example.com/resources/* , use the following Worker script.

export default {
  async fetch(request) {
    const originalUrl = new URL(request.url);
    const rewrittenPath = originalUrl.pathname.replace(/^\/resources/, '');
    const newUrl = `https://your-subdomain.hosted-by-files.com/resources${rewrittenPath}${originalUrl.search}`;

    const response = await fetch(newUrl, request);
    const contentType = response.headers.get("content-type") || "";

    if (contentType.includes("text/html")) {
      return new HTMLRewriter().transform(response);
    }

    return response;
  }
}

After deploying the Worker, open the Triggers section of the Worker configuration and define a route that matches example.com/resources/*. Make sure the route is assigned to the correct zone, which refers to the domain you manage within Cloudflare. In this case, the zone is example.com. The zone must already exist in your Cloudflare account, and your DNS for example.com must be proxied through Cloudflare for the route to take effect.

This setup ensures that Cloudflare runs the Worker whenever a user visits any path under /resources on your domain. When a user accesses a URL like example.com/resources/sample.pdf, the Worker rewrites the request and fetches the file from your Files.com Public Hosting folder. The first request retrieves the file from hosted-by-files.com, and Cloudflare caches it at the edge for future requests. This improves performance and reduces outbound usage on your Files.com site. Users interact only with your branded domain and never see the underlying hosted-by-files.com address.

Handling Mismatched Paths Between Files.com and Your Domain

If the URL path on Files.com matches the route used in Cloudflare (for example, both use /resources/), then both direct file access such as https://example.com/resources/sample.pdf and folder browsing through the index page work as expected without any additional logic. Index pages can be displayed by enabling the Display index page when viewing folders option on the publicly hosted folder in Files.com.

However, if the URL path on Files.com differs from the route exposed on your domain such as Files.com using /myfolder/ while your public route is /resources/—then the default index page generated by Files.com will contain absolute links that won’t resolve correctly under your domain. These mismatched links can break folder navigation and prevent file downloads from the index view.

To address this, you can either update the Public Hosting URL on Files.com to match your route, or upload a custom index.html file with the correct internal paths. Alternatively, you can modify your Worker to rewrite internal links in the index HTML response using HTMLRewriter. Below is the sample code snippet you can add to your Worker for rewriting links:

.on("a", {
  element(el) {
    const href = el.getAttribute("href");
    if (href?.startsWith("/myfolder/")) {
      el.setAttribute("href", href.replace("/myfolder/", "/resources/"));
    }
  }
})

This ensures users can navigate through folders and download files from the index page, even when the path in your Files.com URL differs from the one exposed on your site.

Fastly Compute@Edge

Fastly's Compute@Edge enables you to deploy custom logic at the edge, allowing for dynamic URL path rewriting to manage request routing effectively.

Akamai EdgeWorkers

Akamai's EdgeWorkers provide the capability to manipulate HTML content dynamically at the edge, facilitating URL rewriting and content modification before it reaches the client.

AWS Lambda@Edge

AWS Lambda@Edge allows you to execute functions such as dynamic URL rewriting and request handling at AWS edge locations.

Vercel Edge Middleware

Vercel's Edge Middleware allows for the interception and modification of requests at the edge, enabling hostname rewrites and dynamic routing for your applications.

Netlify Edge Functions

Netlify Edge Functions provide the ability to rewrite requests on one URL to resources available on another URL, allowing for flexible request handling and routing at the edge.