HTTP Request Node — Runtime Behavior#

The HTTP Request node lets workflows make arbitrary outbound HTTP calls and act on the response. Its runtime implementation lives in the external graphon package (imported as graphon.nodes.http_request), not in Dify's own codebase. Dify wires it into the workflow engine through DifyNodeFactory, which injects the SSRF-aware HTTP client, file managers, and a compiled HttpRequestNodeConfig (timeouts, size limits, SSL, retry ceiling) at node creation time 1.

All outbound HTTP from this node is routed through Dify's SSRF proxy layer (api/core/helper/ssrf_proxy.py) before reaching the network.

Output Structure and Non-2xx Status Codes#

A completed HTTP call — regardless of status code — populates the node's outputs dict with four fields:

Non-2xx responses are not failures by default. A 404, for example, returns with result.status == SUCCEEDED and outputs["status_code"] == 404 2. Downstream nodes or conditions must inspect status_code explicitly if branching on HTTP errors is needed.

body vs. files mutual exclusivity: body is set to response.text only when files.value is empty; otherwise it is "". PR #27610 fixed a bug where checking if not files (the object) instead of if not files.value (the value) caused body to always be empty, making failed-request debugging impossible.

The raw request log is available in result.process_data["request"] for all executions 3.

Error Cases That Fail the Node#

The following conditions set result.status = WorkflowNodeExecutionStatus.FAILED and populate result.error / result.error_type:

For all failure cases the workflow engine receives a NodeRunResult with 5:

• status: FAILED
• error: human-readable error string
• error_type: the exception class name as a string
• process_data: request log captured up to the point of failure

Fail Branches and Graph-Level Retry#

Fail-branch routing is controlled by graphon's graph runtime, not by the node itself. When the node returns FAILED, the graph engine follows any configured error edges (fail branches) in the workflow DAG.

Retry coordination: The SSRF transport layer (ssrf_proxy.make_request) has its own exponential-backoff retry loop for status codes [429, 500, 502, 503, 504] (default: 3 retries, backoff 0.5 × 2^(retry-1) seconds) 6. When a workflow also has graph-level retry enabled on the HTTP Request node, both layers previously retried independently, multiplying total attempts: (SSRF_retries + 1) × (graph_retries + 1). PR #33689 fixed this — the node now passes max_retries=0 to the SSRF client when graph-level retry is active, giving the graph handler sole control 6.

After exhausting SSRF retries, a MaxRetriesExceededError is raised, which propagates as a NodeRunResult with FAILED status and surfaces the message "Reached maximum retries for URL {url}" 6.

SSRF Proxy, Blocking, and Version 1.15.0 Behavior Changes#

All HTTP Request node calls pass through a Squid-based SSRF proxy. Dify 1.15.0 changed this to a deny-by-default model — only .marketplace.dify.ai is whitelisted; all other domains and private IPs are blocked 7. This is a breaking change from 1.10.x.

Common post-upgrade symptoms:

• HTTP Request nodes receive 403 Forbidden from the SSRF proxy — surfaced as ToolSSRFError 7.
• "Reached maximum retries for URL" errors when backends are slow: Squid times out → returns 502 → triggers SSRF retry loop → MaxRetriesExceededError 8.

Remediation via environment variables:

# Allow specific domains or private IPs
SSRF_PROXY_ALLOW_PRIVATE_DOMAINS=.example.com
SSRF_PROXY_ALLOW_PRIVATE_IPS=10.x.x.x

# Increase timeouts for slow backends
SSRF_REQUEST_TIMEOUT=1200
SSRF_READ_TIMEOUT=1200

# Reduce SSRF-layer retries (default: 3)
SSRF_DEFAULT_MAX_RETRIES=1

Note: The pre-1.15.0 env var HTTP_REQUEST_MAX_READ_TIMEOUT no longer controls network timeouts; that is now managed by the SSRF proxy layer 8.

Key Configuration Reference#

All values are injected at node creation via build_http_request_config() 1. Defaults shown are from the unit test config 9:

Primary source files:

• api/core/workflow/node_factory.py — DifyNodeFactory wires HTTP dependencies into nodes
• api/tests/unit_tests/core/workflow/nodes/http_request/test_http_request_node.py — node-level tests including timeout and SSL propagation
• api/tests/unit_tests/core/workflow/nodes/http_request/test_http_request_executor.py — executor-level tests including auth error cases
• api/tests/integration_tests/workflow/nodes/test_http.py — end-to-end tests including 404 capture and error outputs
• api/core/helper/ssrf_proxy.py — SSRF transport layer with retry/backoff logic