-
Notifications
You must be signed in to change notification settings - Fork 5.9k
code-server v4 unable to load resources (e.g. new theme) -- requesting to port 80? #4608
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
Comments
When I access code-server via http rather than https, switching theme does work... though the theme previews are not shown so it's a case of choosing the theme via "Browse Color Themes". |
@jsjoeio @code-asher I've set up a demo deployment of code-server v4 over here so that you can play around with it. Password is |
Thank you for the bug report and the demo! Will try to fix this asap. |
This is the Dockerfile used to build the code-server image (it's basically what @code-asher suggested here but with a few extra bits and pieces):
|
Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containing information about the proxied source. We could require users add the relevant configuration or provide the remote authority via a flag but neither are user-friendly options. We can make it work out of the box by changing the frontend to make requests to its current address (which is what we try to set the remote authority to anyway). This actually already happens for the most part except in some UI and logs although recent issues suggest there might be other problems which should be entirely resolved by setting this on the frontend. In other words, the remote authority we set on the backend should never be used so we set it to something invalid to ensure we notice (the alternative is to rip it out but that is probably a bigger patch thus generating more conflicts). One scenario where we might want to set the remote authority from the backend is if the frontend is served from a different location than the backend but that is not supported behavior at the moment. Even if we did support this we still cannot determine the authority from the backend (even for non-proxy scenarios in this case) and would need to add a flag for it so this change would still be necessary. coder/code-server#4604 coder/code-server#4607 coder/code-server#4608
Fixes coder#3410 Fixes coder#4604 Fixes coder#4607 Fixes coder#4608 Fixes coder#4609 Also has the foundation for coder#4619.
Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containing information about the proxied source. We could require users add the relevant configuration or provide the remote authority via a flag but neither are user-friendly options. We can make it work out of the box by changing the frontend to make requests to its current address (which is what we try to set the remote authority to anyway). This actually already happens for the most part except in some UI and logs although recent issues suggest there might be other problems which should be entirely resolved by setting this on the frontend. In other words, the remote authority we set on the backend should never be used so we set it to something invalid to ensure we notice (the alternative is to rip it out but that is probably a bigger patch thus generating more conflicts). One scenario where we might want to set the remote authority from the backend is if the frontend is served from a different location than the backend but that is not supported behavior at the moment. Even if we did support this we still cannot determine the authority from the backend (even for non-proxy scenarios in this case) and would need to add a flag for it so this change would still be necessary. coder/code-server#4604 coder/code-server#4607 coder/code-server#4608
Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containing information about the proxied source. We could require users add the relevant configuration or provide the remote authority via a flag but neither are user-friendly options. We can make it work out of the box by changing the frontend to make requests to its current address (which is what we try to set the remote authority to anyway). This actually already happens for the most part except in some UI and logs although recent issues suggest there might be other problems which should be entirely resolved by setting this on the frontend. In other words, the remote authority we set on the backend should never be used so we set it to something invalid to ensure we notice (the alternative is to rip it out but that is probably a bigger patch thus generating more conflicts). One scenario where we might want to set the remote authority from the backend is if the frontend is served from a different location than the backend but that is not supported behavior at the moment. Even if we did support this we still cannot determine the authority from the backend (even for non-proxy scenarios in this case) and would need to add a flag for it so this change would still be necessary. coder/code-server#4604 coder/code-server#4607 coder/code-server#4608
Trying to determine the remote authority on the backend is brittle because it does not work behind reverse proxies unless they send the right headers containing information about the proxied source. We could require users add the relevant configuration or provide the remote authority via a flag but neither are user-friendly options. We can make it work out of the box by changing the frontend to make requests to its current address (which is what we try to set the remote authority to anyway). This actually already happens for the most part except in some UI and logs although recent issues suggest there might be other problems which should be entirely resolved by setting this on the frontend. In other words, the remote authority we set on the backend should never be used so we set it to something invalid to ensure we notice (the alternative is to rip it out but that is probably a bigger patch thus generating more conflicts). One scenario where we might want to set the remote authority from the backend is if the frontend is served from a different location than the backend but that is not supported behavior at the moment. Even if we did support this we still cannot determine the authority from the backend (even for non-proxy scenarios in this case) and would need to add a flag for it so this change would still be necessary. coder/code-server#4604 coder/code-server#4607 coder/code-server#4608
Having now tried v4.0.1 I can confirm that this issue appears to be resolved... but you knew that already! Nice work! |
Hooray! Thank you for confirming @drmrbrewer 🙌 |
I'm getting the following error in the console when trying to load a new theme (in a fresh v4 installation):
My installation is in this context: #4529 (comment) (just replacing
curl install.sh | sh
withcurl install.sh | sh -s -- --version=4.0.0
).I also have the following
ENTRYPOINT
(i.e. binding to8443
rather than8080
):It all seems to fire up just fine with
v4
... just not able to change theme for a start.I'm also seeing the following (not really doing anything to prompt it):
The text was updated successfully, but these errors were encountered: