Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

wildcard redirects not working from 'firebase serve' #231

Open
rillomas opened this issue May 5, 2017 · 13 comments
Open

wildcard redirects not working from 'firebase serve' #231

rillomas opened this issue May 5, 2017 · 13 comments

Comments

@rillomas
Copy link

rillomas commented May 5, 2017

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
Copy link

gkalpak commented Aug 8, 2017

Still an issue on firebase-tools@3.9.2 😞

@HaykoKoryun
Copy link

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
Copy link

craylward commented Feb 8, 2018

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
Copy link

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
Copy link

gkalpak commented Jan 10, 2020

This seems to work with firebase-tools@7.11.0 (with superstatic@6.0.4) - 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.

gkalpak added a commit to gkalpak/angular that referenced this issue Jan 10, 2020
This simplifies the Firebase redirect config, removing a redundant
pattern (`/api/http`) which is covered by the previous pattern and
dropping an unused named captured segment (`:rest*`).

This change does not affect the redirection behavior for the deployed
apps, but allows the Firebase hosting emulator to work correctly.
(See [here][1] for more info.)

NOTE: Although we are not currently using the Firebase emulator for
      development/testing, we might want to use it in the future.

[1]: firebase/superstatic#231 (comment)
gkalpak added a commit to gkalpak/angular that referenced this issue Jan 10, 2020
This simplifies the Firebase redirect config, removing a redundant
pattern (`/api/http`) which is covered by the previous pattern and
dropping an unused named captured segment (`:rest*`).

This change does not affect the redirection behavior for the deployed
apps, but allows the Firebase hosting emulator to work correctly.
(See [here][1] for more info.)

NOTE: Although we are not currently using the Firebase emulator for
      development/testing, we might want to use it in the future.

[1]: firebase/superstatic#231 (comment)
atscott pushed a commit to angular/angular that referenced this issue Jan 13, 2020
This simplifies the Firebase redirect config, removing a redundant
pattern (`/api/http`) which is covered by the previous pattern and
dropping an unused named captured segment (`:rest*`).

This change does not affect the redirection behavior for the deployed
apps, but allows the Firebase hosting emulator to work correctly.
(See [here][1] for more info.)

NOTE: Although we are not currently using the Firebase emulator for
      development/testing, we might want to use it in the future.

[1]: firebase/superstatic#231 (comment)

PR Close #34726
atscott pushed a commit to angular/angular that referenced this issue Jan 13, 2020
This simplifies the Firebase redirect config, removing a redundant
pattern (`/api/http`) which is covered by the previous pattern and
dropping an unused named captured segment (`:rest*`).

This change does not affect the redirection behavior for the deployed
apps, but allows the Firebase hosting emulator to work correctly.
(See [here][1] for more info.)

NOTE: Although we are not currently using the Firebase emulator for
      development/testing, we might want to use it in the future.

[1]: firebase/superstatic#231 (comment)

PR Close #34726
@zygimantus
Copy link

Does this work? wildcards+redirects?

@tfwyouloveher
Copy link

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

@GuilhermeCouto
Copy link

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
Copy link

prakis commented Jul 18, 2020

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
Copy link

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
Copy link

Teeskid commented Mar 5, 2022

This post helped me this lately.

@SergiSvK
Copy link

SergiSvK commented Mar 28, 2022

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
Copy link

crtag commented Mar 2, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests