-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
Unable to respond normally to HTTPS requests that use ports other than 443 #12792
Comments
Hey @h4ckdepy! 👋 I'm here to help you with bug fixes, questions, and becoming a contributor. Let's squash those bugs together! I found a similar discussion titled "403 Forbidden" which is still open and was last updated on August 7, 2024 [1]. This might be related to the issue you're experiencing with the 403 Forbidden error when using non-standard HTTPS ports. Additionally, there is a known difference in how Dify's HTTP request node and a standard curl command handle HTTPS requests. In a self-hosted Dify instance, the Dify client might fail due to proxy misconfiguration, leading to plain HTTP requests being sent to an HTTPS port, resulting in a 400 Bad Request error. The curl command succeeds because it correctly handles the HTTPS request without encountering the proxy issue. Ensuring proper proxy configuration is crucial for successful communication with the API [2]. You might want to check the proxy settings in your Docker setup, as Dify's Docker configuration can affect HTTP request handling. Ensure that the proxy is properly configured to handle HTTPS requests and maintain the correct protocol when forwarding requests to the Dify API endpoint [3]. To continue talking to Dosu, mention @dosu. Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other |
What you said seems to be fine. I just did the same operation on dify's official website and it was successfully accessed. It seems to be a problem caused by Docker deployment. |
In addition, curl testing is only to prove that network access is not a problem. Use regular interfaces, such as https://www.baidu.com There is no problem with such a website. Only sites that use HTTPS and require a port will encounter problems. How do I configure Docker? @dosu |
To address the issue with Docker deployment affecting HTTPS requests on non-standard ports, you should ensure that your Docker setup is correctly configured to handle such traffic. Here are some steps you can take:
By ensuring these configurations are correctly set, you should be able to resolve the issues with accessing HTTPS sites on non-standard ports in your Docker deployment. To continue talking to Dosu, mention @dosu. Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other |
I just tested the dify service deployed locally on macOS using Docker and encountered the same issue. |
Duplicated, check if this domain is listed in squid.conf, you need to run the curl command in docker container instead of running on your laptop. |
Hi, I'm sorry, I may not have explained the problem clearly. Let me illustrate this issue with clearer examples:
Due to the difference in response from the official website, I believe it is due to certain mechanisms and configurations of Docker that prevent HTTPS sites with ports from responding properly. |
Please check if #13108 resolves this issue. |
Hi, @laipz8200 I have upgraded the version to 0.15.3. Unfortunately, the bug still exists. My interface service is to obtain the export IP, but on the dify deployed in Docker, it is still 403. Is there a debugging document for Docker services? Can quickly locate the code logic related to HTTP request nodes and debug their entire lifecycle. |
Good evening, let me share some of my findings. Command: Show This:
It seems that the problem lies in SSRF-PROXY.PY. According to the code meaning, I used the SSRF_PROXY_HTTP_URL in the system variable which is http://ssrf_proxy:3128 . Make curl proxy request:
After testing a large number of URLs, it was found that only URLs with HTTPS and ports would have 403 errors. |
Based on my findings above I was able to pinpoint that the issue was with the ssrf_proxy:3128 proxy server, which was unable to respond to data normally. So I entered the docker-ssrf_proxy-1 container and found that it was using the Squid service for proxy forwarding. I checked the configuration of the /etc/squid/squid.conf file and found that the acl SSL_ports port was only configured for 443. So I added a new line: Then I used the I'll submit a PR later to update the default squid.conf.template file. Thank you all once again for your hard work and attention. |
Excellent troubleshooting! |
Self Checks
Dify version
0.15.1
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
Use Http Request Node:
Use Curl:
✔️ Expected Behavior
Can respond normally to HTTPS interfaces that use ports other than 443
❌ Actual Behavior
For interfaces that use the HTTPS protocol, as long as the port number is included, for example https://xx.com:6677 , it will display a 403 forbidden error. I will ensure that the host network is functioning properly and curl access is normal
The text was updated successfully, but these errors were encountered: