Feedback Title
Two Hidden Bugs in Dify: Template Variable Parsing Failure and SSRF Protection False Positive
（中文释义：Dify存在两个隐性Bug：模板变量解析失败与SSRF保护误报）
Feedback Type
Please select one:
Bug Report (something broken on the forum)
What’s Your Feedback?
We encountered two hidden bugs during the use of Dify, which caused business blockage and increased troubleshooting costs. The details are as follows:
Bug 1: Template variable {{#code-extract**.cleaned_text#}} is output as-is without parsing**
Phenomenon: The Answer node directly displays the string {{#code-extract.cleaned_text#}} instead of replacing it with the actual content.
Troubleshooting Process: By diving into Dify’s source code, we found the regular expression [a-zA-Z0-9_] used by the variable template parser. It was discovered that the hyphen “-” in the node ID “code-extract” does not match this regular expression, resulting in the parser being unable to recognize the entire variable reference.
Bug 2: HTTP Request node is blocked by SSRF protection (false positive)
Phenomenon: When saving knowledge to the knowledge base, the error “Access to ‘http://nginx/…’ was blocked by SSRF protection” is reported.
Troubleshooting Process (onion-peeling method):
1. First layer: We initially thought it was a Squid proxy configuration issue. We modified custom_allow.conf and added an internal_net ACL to allow internal network target addresses, but the problem still persisted.
2. Second layer: Manual testing from the worker container showed that requesting http://nginx through the proxy could successfully return 200, indicating that the Squid configuration was correct.
3. Third layer: Checking the Squid access logs revealed that the request from Dify chatflow actually returned 401 Unauthorized instead of 403. Dify’s ssrf_proxy.py source code detected 401 plus Squid’s Via header and incorrectly judged it as SSRF interception.
Root Cause: The header parsing logic of Dify’s HTTP Request node splits by newline character \n, with one key: value per line. Two headers in the DSL were written in the same line: “Authorization: Bearer *** Content-Type: application/json”. After parsing, the value of Authorization became “Bearer *** Content-Type: application/json”, making the API key invalid, leading to 401, which was falsely reported by the SSRF detection logic.
Screenshots (if applicable)
Sorry, due to my inexperience, I accidentally deleted the old Chatflow but found the following error message in the work history.
I seem to only be able to upload one image…
Why Is This Important?
1. For Bug 1: The variable naming rules are not clearly prompted, and the front end does not report errors when illegal characters (such as hyphens) are used. This will cause developers to spend a lot of time troubleshooting the root cause of variable parsing failures, affecting development efficiency and business progress.
2. For Bug 2: The SSRF error message is misleading. It clearly is an authentication failure (401) but is packaged as an SSRF interception error. This will mislead developers to focus on proxy configuration troubleshooting, ignoring the real root cause (header parsing error), which greatly increases the difficulty and cost of problem solving.
Both bugs are hidden and not easy to be found, which will bring unnecessary trouble to Dify users and affect the user experience and trust in the product.
Suggested Solution (optional)
For Bug 1 (Template Variable Parsing Failure):
1. Optimize the variable template parser to support hyphens “-” in node IDs (if the product design allows), or clearly define variable naming rules in the documentation and front-end prompts.
2. Add front-end error prompts: When the node ID contains illegal characters (not matching [a-zA-Z0-9_]), a clear error message is displayed to remind developers to modify the node ID.
3. Supplement relevant instructions in the official documentation to clearly inform users of the variable naming rules and prohibited characters.
For Bug 2 (SSRF Protection False Positive):
1. Optimize the SSRF detection logic in ssrf_proxy.py to distinguish between real SSRF interception (403) and authentication failure (401), avoiding false positives caused by 401 + Via header.
2. Optimize the error message prompt: When a 401 error occurs, directly prompt “Authentication failed” instead of packaging it as an SSRF interception error, to guide developers to troubleshoot authentication-related issues.
3. Optimize the header parsing logic of the HTTP Request node: Add a check for header formatting. If multiple headers are written in the same line, a prompt is given to remind developers to split them by newline characters.
Browser/Device (for bug reports)
Browser: Chrome 124.0.6367.155
Device: Desktop
Operating System: Windows 11 Professional
Additional Context
1. The above bugs were found during the process of configuring Dify chatflow and saving knowledge to the knowledge base, and can be stably reproduced according to the described steps.
2. We have temporarily solved the problem through workarounds (modifying node ID, adjusting HTTP header configuration and authentication method), but the root cause still exists and needs to be fixed by the official.
3. We hope that the official can pay attention to these two hidden bugs and optimize them in subsequent versions to improve the user experience.