firebase redirects and cache headers

[Derek Abram]

I am attempting to set the cache headers and redirects per the hosting docs. But for some reason neither is working. I know my firebase.json file at least partially works, as it deploys to the proper firebase.

My goal is to heavily cache assets and redirect all routes to the root route.

This is my firebase.json, does anyone see any issues (I use cache busting for my js/css so don't worry about those numbers):

{

  "firebase": "*******",

  "public": "app/prod",

  "ignore": [

    "firebase.json",

    "**/node_modules/**"

  ],

  "rules": "rules.json",

  "redirects": [ {

    "source" : "/*",

    "destination" : "/",

    "type" : 301

  } ],

  "headers": [ {

    "source" : "**/*.@(eot|otf|ttf|ttc|woff)",

    "headers" : [ {

      "key" : "Access-Control-Allow-Origin",

      "value" : "*"

    } ]

    }, {

    "source" : "**/*.@(js|css)",

    "headers" : [ {

      "key" : "Cache-Control",

      "value" : "max-age=31000000"

    } ]

    }, {

    "source" : "**/*.@(jpg|jpeg|gif|png|svg)",

    "headers" : [ {

      "key" : "Cache-Control",

      "value" : "max-age=2500000"

    } ]

  } ]

}

[Chris Raynor]

What version of firebase-tools are you using? Only v1.1.0 and later support the new parameters

Chris

[Chris Raynor]

Also, a rewrite might better suite your needs - redirect rules are run before anything else and will bypass all other logic and simply return an http 301 status code to the destination.

For example, with your current rules, a request to '/foo.jpg' will return a 301 to '/', which tells the browser to then try a completely new, separate request to '/'. It will then get what's there without any additional headers as the new request does not end in '.jpg'.

If your glob for the redirect did what I assume you intended from your comment, no file would be served with the additional headers (right now it just applies to any file in the root folder)

What I imagine you are looking to do is a rewrite, where the server will respond to any request that matches with the content specified at the 'destination' - for example, with a rewrite instead, the same request above to '/foo.jpg' would return the contents of foo.jpg if it existed, with the additional headers, and if the file didn't exist it would simply serve the contents of '/' without changing the URL.

The way you would do that is with the rewrite rule in the docs:

1. "rewrites": [ {
2. "source": "**",
3. "destination": "/index.html"
4. } ]

Hope that helps

Chris

[Derek Abram]

Ha, you are fixing my problems left and right. Thanks, yes those two comments have me working perfectly.

On another note, do you guys recommend a service like pingdom for mission critical apps, or does that become less useful since you guys are overseeing the ops?

On Friday, August 15, 2014 3:18:06 PM UTC-7, Derek Abram wrote:

[Chris Raynor]

We do have an extensive monitoring system in place to determine the health of Hosting as a whole, which in part itself does use Pingdom and we're happy with them.

However, that doesn't cover everything that you might want to monitor as the owner of a site - there may be other reasons than just Hosting going down that mean your site could go down, such as a third-party dependency on some critical part of your site (say if jQuery was unavailable, for example, or some font provider was being slow) or somebody might accidentally deploy a botched version of your site (with local resources, or incorrect rewrite rules, say). You might also want to track page load latency over time and other metrics to see how changes effect performance.

I'm also not pretending that Hosting, or our monitoring of it, is infallible, and would rather that we had too much than too little when it comes to monitoring - so that if a problem occurs we can fix it as soon as possible. In short, I recommend you keep us honest and at least have some basic monitoring in place if it's important.

Glad I could help, and thanks for using Hosting

Chris