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

[🐞] useLocation() always returns "http" protocol, even though it is on https #6382

Open
jsaad-syncoms opened this issue May 24, 2024 · 4 comments
Labels
STATUS-1: needs triage New issue which needs to be triaged TYPE: bug Something isn't working

Comments

@jsaad-syncoms
Copy link

jsaad-syncoms commented May 24, 2024

Which component is affected?

Qwik City (routing)

Describe the bug

I have deployed my app to a live server, with https, and useLocation() always returns "http:" as protocol. This leads to the following error where I need to change URL parameteres for certain pages:

DOMException: Failed to execute 'replaceState' on 'History': A history state object with URL 'http://[...myURL]' cannot be created in a document with origin 'https://[...myURL]' and URL 'https://[...myURL]'.

At the moment, it looks like I'm gonna just to have use the standard document.location.

Reproduction

https://stackblitz.com/edit/qwik-starter-ddc5id?file=src%2Froutes%2Findex.tsx

Steps to reproduce

Deply any code to a live server with https and console.log(location.url).

System Info

NAME="Rocky Linux"
VERSION="9.3 (Blue Onyx)"
ID="rocky"
ID_LIKE="rhel centos fedora"
VERSION_ID="9.3"
PLATFORM_ID="platform:el9"
PRETTY_NAME="Rocky Linux 9.3 (Blue Onyx)"
ANSI_COLOR="0;32"
LOGO="fedora-logo-icon"
CPE_NAME="cpe:/o:rocky:rocky:9::baseos"
HOME_URL="https://rockylinux.org/"
BUG_REPORT_URL="https://bugs.rockylinux.org/"
SUPPORT_END="2032-05-31"
ROCKY_SUPPORT_PRODUCT="Rocky-Linux-9"
ROCKY_SUPPORT_PRODUCT_VERSION="9.3"
REDHAT_SUPPORT_PRODUCT="Rocky Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="9.3"

Additional Information

No response

@jsaad-syncoms jsaad-syncoms added STATUS-1: needs triage New issue which needs to be triaged TYPE: bug Something isn't working labels May 24, 2024
@PatrickJS
Copy link
Member

this is technically working as expected since useTask is running on the server and we pass the url from the server environment you're on. so in your adapter for your platform you can update the url to the correct url you want or it depends on which adapter you're deploying with

image

image

the fix would be to make sure your platform

@PatrickJS
Copy link
Member

ok I see what you're saying it's not really clear and only works correctly in certain adapters

@jsaad-syncoms
Copy link
Author

jsaad-syncoms commented May 28, 2024

Hi @PatrickJS - thanks for your reply. So this is the adapter config being used in the project:

export default extendConfig(baseConfig, () => {
  return {
    build: {
      ssr: true,
      rollupOptions: {
        input: ["src/entry.express.tsx","@qwik-city-plan"],
      },
    },
    plugins: [
      nodeServerAdapter({ name: 'express'})
    ],
  };
});

Is there anything I can do in this config to remedy the situation?

@PatrickJS PatrickJS changed the title [🐞]useLocation() always returns "http" protocol, even though it is on https [🐞] useLocation() always returns "http" protocol, even though it is on https May 28, 2024
@wakonp
Copy link

wakonp commented Jul 31, 2024

Hi,
I can relate to that problem. In my setup, the qwik application is running within a cluster, and there are multiple proxies in front of it. It is necessary to always include the X-Forwarded-Proto Header within your proxy settings. Qwik uses the header to change the protocol of the origin.

It was confusing because I always set the ORIGIN env variable, and requests sent directly to qwik (without going through the proxies) always returned the correct URL.

I hope this is helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
STATUS-1: needs triage New issue which needs to be triaged TYPE: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants