Redirect running despite shadowed file existing in deploying

Hello devotox!
I have seen you post against the process to run leverge browser cache for static assets, browser cookie and http headers.
I am working on a website, that has built up before 4 years in bootstrap 3 free responsive HTML template.

As of now trend has been changed, bootstrap 4 I in current trend and that too be using serverless, cdn for running, minifying, compressing and inlining css, jQuery and js files offered by maxbootstrapcdn, stackpath, angular, ajax, clouldflare etc…

I wanted to know how can I migrate my website from bootstrap3 to bootstrap 4 using above mentioned server less cdn urls. I am not a web developer, I am a beginner, who can upload the website files. Editing and changing, text, images and some other onpage seo related work.

And also let me know the way to use the functions for assigning cache , cookies get and response headers.

If you can help me, than please let me know the way to do it without paying. My website I and and you can email me also with the positive response at

With Regards
Akshita Patel

@devotox, it seem like this might be a bug. We’ll file an issue on this. We’ll update here if and when we have a fix out for it.

@Akshita_Patel, since you post is unrelated to this thread, please create a separate post by clicking the ‘new topic’ button on the main page:

Hi @devotox, I’ve made a change to how your site’s redirects work. Can you check if your redirect rules work now?

Was this made in the settings somewhere that I can see or in the netlify.toml? I ask because now that I have been able to look at this my site as automatically deployed at least 3 times (wooo robots ay)

At the moment with the latest deploy I still have the same problem but like I said many deploys have happened since your message

Can you tell me which urls are still getting redirected? Since your build seems to change all your filenames, I recommend also taking a look at the post about making the most of our CDN cache

Anything in the /assets/ directory

Filenames are changed depending on md5 hashes. This will slow down when development slows down

Hi, we have an experimental fix for the issue that you describe and have enabled it for your site. Could you re-deploy your site and see if that helps?

Also, I just wanted to point out that you have a redirect rule conflict here:

  status = 200
  force = false
  from = "/*"
  to = "/.netlify/functions/fastboot/:splat"

  status = 200
  force = false
  from = "/*"
  to = "/index.html"

Basically, that second rule will never get used.

Thank you. Deploying now to test.

Yes i know the second will never run and that is intentional. I have them both still in there because i was commenting out the functions redirect every time i needed the site to actually work

Please let us know how the testing goes, @devotox. We’re happy to answer if there are other questions as well.

I am still getting a 502 on requests that should hit the filesystem after my latest deploy.

6:20:18 PM: {"level":"info","time":1582914018317,"pid":8,"hostname":"","reqId":4,"req":{"method":"GET","url":"/engines-dist/home/assets/engine.js"},"v":1,"message":"incoming request","environment":"production","label":"zenunu","timestamp":"2020-02-28T18:20:18.317Z"}

Hi, @devotox, that IP address isn’t routable (it is a local-link address) and therefore I cannot search our logs for it.

We still need the x-nf-request-id or the information it replaces to trace the requests returning the 502s. Would you please send us that information?


    "level": "info",
    "time": 1583163637524,
    "pid": 7,
    "hostname": "",
    "message": "Fastboot Visit",
    "hashedKey": "82e8be118c5db25d4d824978014156ca7cbf8b05",
    "cacheHit": false,
    "request": {
        "url": "/assets/images/icons/icon-16-3cf27b93565c6c1e5359b2ea256f0416.png",
        "host": "",
        "port": 80,
        "path": "/assets/images/icons/icon-16-3cf27b93565c6c1e5359b2ea256f0416.png",
        "method": "GET",
        "protocol": "https",
        "location": "",
        "headers": {
            "accept": "image/webp,image/apng,image/*,*/*;q=0.8",
            "accept-encoding": "br, gzip",
            "accept-language": "en-GB,en-US;q=0.9,en;q=0.8",
            "client-ip": "",
            "cookie": "ember_simple_auth-session=%7B%22authenticated%22%3A%7B%7D%7D; ember_simple_auth-session-expiration_time=86400",
            "referer": "",
            "sec-fetch-mode": "no-cors",
            "sec-fetch-site": "same-origin",
            "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36",
            "via": "https/2 Netlify[b5fe4bec-7a3d-48f7-af89-114c527bb1a1] (ApacheTrafficServer/7.1.9)",
            "x-bb-ab": "0.246849",
            "x-bb-client-request-uuid": "b5fe4bec-7a3d-48f7-af89-114c527bb1a1-3663412",
            "x-bb-ip": "",
            "x-bb-loop": "1",
            "x-country": "GB",
            "x-forwarded-for": "",
            "x-forwarded-proto": "https",
            "x-language": "en,en,en;q=0.8",
            "x-nf-client-connection-ip": "",
            "x-apigateway-event": "%7B%22path%22%3A%22%2Fassets%2Fimages%2Ficons%2Ficon-16-3cf27b93565c6c1e5359b2ea256f0416.png%22%2C%22httpMethod%22%3A%22GET%22%2C%22headers%22%3A%7B%22accept%22%3A%22image%2Fwebp%2Cimage%2Fapng%2Cimage%2F*%2C*%2F*%3Bq%3D0.8%22%2C%22accept-encoding%22%3A%22br%2C%20gzip%22%2C%22accept-language%22%3A%22en-GB%2Cen-US%3Bq%3D0.9%2Cen%",
            "x-apigateway-context": "%7B%22callbackWaitsForEmptyEventLoop%22%3Afalse%2C%22functionVersion%22%3A%22%24LATEST%22%2C%22functionName%22%3A%228ab29a7c639d7e8e0eeecaf0a2b6d86cb758fd5d01f3df2444eb4ab2b031aef1%22%2C%22memoryLimitInMB%22%3A%221024%22%2C%22logGroupName%22%3A%22%2Faws%2Flambda%2F8ab29a7c639d7e8e0eeecaf0a2b6d86cb758fd5d01f3df2444eb4ab2b031aef1%22%2C%22logStreamName%22%3A%222020%2F03%2F02%2F%5B%24LATEST%5D483b81943be84320b7c025354f81d466%22%2C%22clientContext%22%3A%7B%22custom%22%3A%7B%22netlify%22%3A%22eyJzaXRlX3VybCI6Imh0dHBzOi8vemVudW51Lm5ldGxpZnkuY29tIn0%3D%22%7D%7D%2C%22invokedFunctionArn%22%3A%22arn%3Aaws%3Alambda%3Aus-east-1%3A673769985865%3Afunction%3A8ab29a7c639d7e8e0eeecaf0a2b6d86cb758fd5d01f3df2444eb4ab2b031aef1%22%2C%22awsRequestId%22%3A%221058669a-c566-4e35-b322-93a669ebb8e6%22%7D",
            "host": "",
            "content-length": "0",
            "x-forwarded-host": "",
            "location": ""
    "response": {
        "_headers": {}
    "v": 1,
    "environment": "production",
    "label": "zenunu",
    "timestamp": "2020-03-02T15:40:37.524Z"


x-nf-request-id: dfe167ba-dfd9-4edb-81c3-557b6da929e4-9928409

Hi, @devotox. Thank you for sending those two examples.

For both the x-nf-request-ids (dfe167ba-dfd9-4edb-81c3-557b6da929e4-9928409 and b5fe4bec-7a3d-48f7-af89-114c527bb1a1-3663412), I can confirm that the file in question exists in that deploy but that the HTTP request is being proxied to the function instead.

This is incorrect behavior as the rule is not a force or 200! (with the !) so the URL should send the file in the deploy and not proxy the HTTP request.

We do have an open issue tracking this. I’m also researching a possible workaround in the meantime.

We’ll update this community topic again as soon as I know more about the workaround and if/when the issue itself is known to be resolved.

@luke Thank you guys for being on top of this and your quick replies. could you point me to the internal ticket to also watch that

Just got Luke’s proposed fix in place (a feature flag we applied to the zenunu site). Could you trigger one more deploy to apply that configuration, and let us know if it works better or no?

@luke @fool I deployed twice and tested in an incognito window. You will see from the request ID below that we still hit the serverless function when requesting an image on disk.

x-nf-request-id: 4c421348-8893-4880-ab87-69a48137c368-2592124

Hi, @devotox, I did confirm that the HTTP request for the asset associated with the most recent x-nf-request-id header (4c421348-8893-4880-ab87-69a48137c368-2592124) was proxied in error. This occurred even with the workaround in place (which is the behavior the open issue covers).

The open issue is on a private Git repository so there is no public URL to share. However, that issue and this community topic are now cross-linked for tracking. If/when the issue is known to be resolved, we’ll follow-up here to let you know about it.