wildcard redirects not working from 'firebase serve'

[rillomas]

I'm trying to redirect some requests from firebase serve to pub serve (Dart's local server) on a local machine, but the wildcard redirects seem to be not working.

I'm using the following firebase.json

{
  "database": {
    "rules": "database.rules.json"
  },
  "hosting": {
    "public": "web",
    "redirects": [{
      // Following works:
      // "source" : "/packages/web_components/webcomponents-lite.min.js",
      // "destination" : "http://localhost:8080/packages/web_components/webcomponents-lite.min.js",

      // Following doesn't work:
      "source" : "/packages/:file*",
      "destination" : "http://localhost:8080/packages/:file*"
    }]
  }
}

firebase-cli version: 3.7.0 superstatic version: 4.1.0 Windows 10 Pro x64

[gkalpak]

Still an issue on [email protected] 😞

[HaykoKoryun]

Just ran some unit tests and it fails on redirects with segments in urls, here's the output:

mocha test/unit/middleware/redirects.spec.js

  redirect middleware
    √ skips the middleware if there are no redirects configured (46ms)
    √ skips middleware when there are no matching redirects
    √ redirects to a configured path
    √ redirects to a configured path with a custom status code
    √ adds leading slash to all redirect paths
    √ redirects using glob negation
    1) redirects using segments in the url path
    2) redirects a missing optional segment
    3) redirects a present optional segment
    4) redirects a splat segment
    5) redirects using segments in the url path with a 302
    √ redirects to external http url
    √ redirects to external https url
    √ preserves query params when redirecting
    √ appends query params to the destination when redirecting
    √ preserves query params when redirecting to external urls
    6) preserves query params when redirecting with captures

  11 passing (170ms)
  6 failing

[craylward]

Using Firebase Hosting and experiencing a related issue when attempting to use redirects with a combination of glob negation and segment capturing.

"redirects": [{
     "source" : "/one/!(a|b|c)/:end.html",
     "destination" : "/one/d/:end.html",
     "type" : 302
     }]

Does not redirect /one/z/test.html to /one/d/test.html as expected.

[badmansan]

2 years passed, version 6.9.2 still have this error lol, the code from official doc is not working localy

 "redirects": [ {
    "source": "/blog/:post*",  // captures the entire URL segment beginning at "post"
    "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value
    "type": 301
  }, {
    "source": "/users/:id/profile",  // captures only the URL segment "id", but nothing following
    "destination": "/users/:id/newProfile",  // includes the URL segment identified and caputured by the "source" value
    "type": 301
  } ]

[gkalpak]

This seems to work with [email protected] (with [email protected]) - possibly earlier versions too.

However, there seems to be a couple of limitations/deviations from the actual server (used for deployed apps):

1. The destination must include the trailing * for named segments. I.e. {source: '/foo/:rest*', destination: '/bar/:rest*'} works file, but {source: '/foo/:rest*', destination: '/bar/:rest'} (without the trailing * in destination) does not work with the emulator (while it does work on the deployed app). (Obviously, the work-around is to include the trailing * in the destination.)

2. If the source contains a named segment, the destination must include a named segment as well. I.e. {source: '/foo/:rest*', destination: '/bar/:rest*'} works as expected, but {source: '/foo/:rest*', destination: '/bar/baz'} does not work with the emulator (while it does work on the deployed app). (The work-around is to replace the named segment in the source with /** (since the named segment was not used in the destination anyway).)

It is not great that the behavior of the emulator/devserver deviates from that of the deployed app, but at least there are work-arounds available.

[zygimantus]

Does this work? wildcards+redirects?

[tfwyouloveher]

currently working (8.1.1) with relative redirects but not absolute ones :unamused:

[GuilhermeCouto]

Not working here with everything up-to-date. I tried all that you can imagine to do this below:

"redirects": [ { "source": "/a/(any)", "destination": "../a?u=(any)", "type": 301 }]

Can somebody help me?

[prakis]

The official example itself is not working in emulator

  "redirects": [ {
    "source": "/blog/:post*",  // captures the entire URL segment beginning at "post"
    "destination": "https://blog.myapp.com/:post", // includes the entire URL segment identified and captured by the "source" value
    "type": 301
  }, {
    "source": "/users/:id/profile",  // captures only the URL segment "id", but nothing following
    "destination": "/users/:id/newProfile",  // includes the URL segment identified and captured by the "source" value
    "type": 301
  } ]

[Mauratay]

Having the same issue, as far as I know query parameters are not supported for "source" in redirects, just wondering if that's the current Firebase standpoint.

[Teeskid]

This post helped me this lately.

[SergiSvK]

To me this if it has worked for me

{
    "hosting": {
        "cleanUrls": true,
        "trailingSlash": false,
        "public": "public",
        "ignore": [
            "firebase.json",
            "**/.*",
            "**/node_modules/**"
        ],
        "redirects": [
            {
                "source": "/index.html",
                "destination": "/index",
                "type": 301
            },
            {
                "source": "/networks.html",
                "destination": "/networks",
                "type": 301
            }
        ]
    }
}

[crtag]

A trivial configuration like

    "redirects": [ {
      "source": "/a",
      "destination": "/b",
      "type": 302
    } ]

does not work in the emulator, but works in deployed version. Is it a known limitation?