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

Incorrect protocol and port detection when APP_WEB_URL is unset behind Nginx #13070

Open
5 tasks done
osaimi opened this issue Jan 27, 2025 · 1 comment · May be fixed by #13102
Open
5 tasks done

Incorrect protocol and port detection when APP_WEB_URL is unset behind Nginx #13070

osaimi opened this issue Jan 27, 2025 · 1 comment · May be fixed by #13102
Labels
🐞 bug Something isn't working

Comments

@osaimi
Copy link
Contributor

osaimi commented Jan 27, 2025

Self Checks

  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue,否则会被关闭。谢谢!:)
  • Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

The Dify frontend relies on the backend to generate some frontend URLs. If APP_WEB_URL is not set, the backend uses request.url_root to determine the URL. However, when running Dify in a Docker environment behind Nginx, request.url_root fails to correctly detect the protocol and port.
 

  • Protocol Issue: When Nginx uses HTTP but the external proxy uses HTTPS, the protocol is incorrectly detected as HTTP instead of HTTPS.
  • Port Issue: The port is incorrectly determined because it is tied to NGINX_PORT.
     
    I cannot set APP_WEB_URL because clients access my Dify instance from multiple hosts and ports. As a result, leaving APP_WEB_URL unset causes incorrect frontend URL generation in dynamic setups with multiple hosts, ports, or proxies.
     
    Here is a screenshot of what’s happening:

Image

2. Additional context or comments

I propose that we remove APP_WEB_URL completely and let the frontend use window.location.origin instead. Here is a proof of concept for the proposal: #13065

3. Can you help us with this feature?

  • I am interested in contributing to this feature.
@dosubot dosubot bot added the 🐞 bug Something isn't working label Jan 27, 2025
@osaimi
Copy link
Contributor Author

osaimi commented Jan 28, 2025

Werkzeug’s ProxyFix middleware uses X-Forwarded-* headers to update the WSGI environ. By default, it tries to use two headers: X-Forwarded-For and X-Forwarded-Proto. This was added to Dify’s extensions in this PR.

def __init__(
   self,
   app: WSGIApplication,
   x_for: int = 1,
   x_proto: int = 1,
   x_host: int = 0,
   x_port: int = 0,
   x_prefix: int = 0,
) -> None:

 
It might be worth extending ext_proxy_fix.py to handle additional X-Forwarded-* headers.
 
 
The integer values in the ProxyFix configuration indicate the number of reverse proxies the middleware should trust. As a result, this setup will not work correctly beyond a single reverse proxy without further configuration.

@osaimi osaimi linked a pull request Jan 28, 2025 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐞 bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant