Skip to content

fix: add SSRF timeout configuration and validation checks#32483

Closed
JaneCrystall wants to merge 3 commits into
langgenius:mainfrom
JaneCrystall:fix/ssrf-timeout
Closed

fix: add SSRF timeout configuration and validation checks#32483
JaneCrystall wants to merge 3 commits into
langgenius:mainfrom
JaneCrystall:fix/ssrf-timeout

Conversation

@JaneCrystall
Copy link
Copy Markdown
Contributor

Important

  1. Make sure you have read our contribution guidelines
  2. Ensure there is an associated issue and you have been assigned to it
  3. Use the correct syntax to link this PR: Fixes #<issue number>.

Summary

fix #31098
This PR fixes the workflow HTTP Request node timing out at around 120 seconds, even when HTTP_REQUEST_MAX_READ_TIMEOUT is set higher.

1. Root cause

The request goes through ssrf_proxy (Squid) first, and Squid had hardcoded timeouts in squid.conf.template:

  • request_timeout 2 minutes
  • read_timeout 2 minutes

So the proxy terminated long-running requests before app-level timeout settings could take effect.

2. Changes made

Made Squid timeouts configurable via environment variables in squid.conf.template:

  • request_timeout ${SSRF_REQUEST_TIMEOUT} seconds
  • read_timeout ${SSRF_READ_TIMEOUT} seconds

Added default timeout variables (seconds) in .env.example:

  • SSRF_REQUEST_TIMEOUT=1200
  • SSRF_READ_TIMEOUT=1200

Passed new variables into the ssrf_proxy service in docker-compose-template.yaml:

  • SSRF_REQUEST_TIMEOUT: ${SSRF_REQUEST_TIMEOUT:-1200}
  • SSRF_READ_TIMEOUT: ${SSRF_READ_TIMEOUT:-1200}

Regenerated compose output:

  • docker-compose.yaml

3. Test/validation updates

Since similar config tests already exist, this PR extends pytest_config_tests.py to verify:

  • New keys exist in .env.example
  • New keys are present in docker-compose.yaml
  • New env mappings exist in docker-compose-template.yaml x-shared-env
  • Squid template contains the expected timeout lines with env placeholders and seconds

4. Verification run

pytest_config_tests.py
Result: All tests passed!

5. Impact

SSRF proxy timeout is now configurable (default 1200s) instead of fixed at 120s, preventing premature proxy-layer timeout for long-running HTTP node requests.

Screenshots

Before After
... ...

Checklist

  • This change requires a documentation update, included: Dify Document
  • I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran make lint and make type-check (backend) and cd web && npx lint-staged (frontend) to appease the lint gods

@dosubot dosubot Bot added size:M This PR changes 30-99 lines, ignoring generated files. 🌊 feat:workflow Workflow related stuff. labels Feb 23, 2026
@gemini-code-assist
Copy link
Copy Markdown
Contributor

Summary of Changes

Hello @JaneCrystall, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where HTTP Request nodes in workflows would prematurely time out due to hardcoded 120-second limits within the Squid SSRF proxy. The changes introduce configurable request_timeout and read_timeout settings for the Squid proxy, allowing users to specify longer durations via environment variables. This enhancement ensures that long-running HTTP requests are no longer terminated by the proxy before application-level timeouts can take effect, significantly improving the reliability of workflows involving extended external calls.

Highlights

  • Configurable SSRF Proxy Timeouts: Introduced configurable request_timeout and read_timeout settings for the Squid SSRF proxy, replacing previously hardcoded 2-minute limits.
  • New Environment Variables: Added SSRF_REQUEST_TIMEOUT and SSRF_READ_TIMEOUT environment variables with default values of 1200 seconds to .env.example.
  • Docker Compose Integration: Integrated the new timeout variables into the ssrf_proxy service configuration within docker-compose-template.yaml and docker-compose.yaml.
  • Enhanced Configuration Validation: Expanded configuration tests in pytest_config_tests.py to validate the presence and correct mapping of the new SSRF timeout settings across relevant files.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog
  • dev/pytest/pytest_config_tests.py
    • Defined new constants for SSRF timeout configuration keys and expected template lines.
    • Added new test cases to verify that SSRF_REQUEST_TIMEOUT and SSRF_READ_TIMEOUT are present in .env.example, docker-compose.yaml's x-shared-env, and correctly mapped in docker-compose-template.yaml and squid.conf.template.
  • docker/.env.example
    • Added SSRF_REQUEST_TIMEOUT and SSRF_READ_TIMEOUT with default values of 1200 seconds, along with comments.
  • docker/docker-compose-template.yaml
    • Included SSRF_REQUEST_TIMEOUT and SSRF_READ_TIMEOUT as environment variables for the ssrf_proxy service, using default values if not set.
  • docker/docker-compose.yaml
    • Updated the x-shared-env section to include SSRF_REQUEST_TIMEOUT and SSRF_READ_TIMEOUT.
    • Added SSRF_REQUEST_TIMEOUT and SSRF_READ_TIMEOUT to the ssrf_proxy service's environment variables.
  • docker/ssrf_proxy/squid.conf.template
    • Modified request_timeout and read_timeout directives to use ${SSRF_REQUEST_TIMEOUT} and ${SSRF_READ_TIMEOUT} environment variables, respectively, instead of hardcoded values.
Activity
  • The author identified the root cause of HTTP Request node timeouts as hardcoded Squid proxy timeouts.
  • Configuration changes were implemented to make Squid timeouts configurable via environment variables.
  • New test cases were added to pytest_config_tests.py to validate the new configuration.
  • The verification run of pytest_config_tests.py passed successfully.
  • The author confirmed that documentation updates are required and have been addressed.
  • The author confirmed that tests were added for each change and that linting and type-checking passed.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

The pull request introduces configurable timeout settings for the SSRF proxy, addressing a hardcoded timeout issue in Squid. This change enhances the flexibility and reliability of long-running HTTP requests within the workflow. The changes include adding new environment variables, updating Docker Compose configurations, and modifying the Squid template. Additionally, new test cases have been added to validate these configurations, ensuring proper integration and functionality. The changes are well-documented and appear to resolve the reported issue effectively.

@dosubot dosubot Bot mentioned this pull request Mar 9, 2026
6 tasks
@crazywoola
Copy link
Copy Markdown
Member

Thanks for the contribution. This PR has been open for more than three months and the CI checks are currently failing, so we're closing it as stale to keep the review queue manageable. If this is still relevant, please feel free to reopen or submit a new PR with the failing checks addressed.

@crazywoola crazywoola closed this May 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🌊 feat:workflow Workflow related stuff. size:M This PR changes 30-99 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reached maximum retries (0) for URL after 120s

2 participants