HTTP Request Node Unable to Access File from Start Node When Using Remote URL in Workflow API Call #16329

Closed
opened 2026-02-21 19:25:40 -05:00 by yindo · 1 comment
Owner

Originally created by @dlmu-lq on GitHub (Aug 21, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :)
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.7.2

Cloud or Self Hosted

Self Hosted (Source)

Steps to reproduce

Configure a workflow with:
A Start node to accept a file input.
An HTTP request node intended to process the file.
Trigger the workflow using the API call with a remote_url to send the file link.
Observe that the file is not read successfully by the HTTP request node.

✔️ Expected Behavior

The HTTP request node should correctly read and process the file when it is provided through the remote_url method in an API-triggered workflow.

Actual Behavior

The file is not being accessed or processed by the HTTP request node when provided as a remote_url in an API call.

Originally created by @dlmu-lq on GitHub (Aug 21, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交,否则会被关闭 :) - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.7.2 ### Cloud or Self Hosted Self Hosted (Source) ### Steps to reproduce Configure a workflow with: A Start node to accept a file input. An HTTP request node intended to process the file. Trigger the workflow using the API call with a remote_url to send the file link. Observe that the file is not read successfully by the HTTP request node. ### ✔️ Expected Behavior The HTTP request node should correctly read and process the file when it is provided through the remote_url method in an API-triggered workflow. ### ❌ Actual Behavior The file is not being accessed or processed by the HTTP request node when provided as a remote_url in an API call.
yindo added the 🐞 bug🌊 feat:workflow labels 2026-02-21 19:25:41 -05:00
yindo closed this issue 2026-02-21 19:25:41 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Aug 21, 2025):

This is a known bug in Dify v1.7.2: when you trigger a workflow via API and provide a file using remote_url, the HTTP request node fails to process the file because the workflow runtime does not properly fetch or convert the remote file for downstream nodes. The root cause is that files uploaded via remote_url have relative_id=None, so the HTTP request node executor filters them out, resulting in an empty request body or a __multipart_placeholder__ instead of the actual file data [source].

Recent releases have fixed this by improving remote file handling and multipart/form-data boundary logic in the HTTP request node [source]. Upgrading to the latest Dify version is the recommended solution.

If you can't upgrade, possible workarounds are: use a code node to manually fetch and send the file with explicit multipart encoding, or ensure at least one field is of type file (even a dummy/empty file) to force multipart/form-data encoding [source]. Also, make sure your workflow file variables are set as Array[File], and for S3 storage, the node must fetch the actual file content from S3 and include it in the payload—not just the file URL or metadata.

For more details and patch references, see:

To reply, just mention @dosu.


How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 21, 2025): <!-- Answer --> This is a known bug in Dify v1.7.2: when you trigger a workflow via API and provide a file using `remote_url`, the HTTP request node fails to process the file because the workflow runtime does not properly fetch or convert the remote file for downstream nodes. The root cause is that files uploaded via `remote_url` have `relative_id=None`, so the HTTP request node executor filters them out, resulting in an empty request body or a `__multipart_placeholder__` instead of the actual file data [[source](https://github.com/langgenius/dify/issues/22977)]. Recent releases have fixed this by improving remote file handling and multipart/form-data boundary logic in the HTTP request node [[source](https://github.com/langgenius/dify/pull/23903)]. Upgrading to the latest Dify version is the recommended solution. If you can't upgrade, possible workarounds are: use a code node to manually fetch and send the file with explicit multipart encoding, or ensure at least one field is of type `file` (even a dummy/empty file) to force multipart/form-data encoding [[source](https://github.com/langgenius/dify/issues/24089#issuecomment-3195342324)]. Also, make sure your workflow file variables are set as `Array[File]`, and for S3 storage, the node must fetch the actual file content from S3 and include it in the payload—not just the file URL or metadata. For more details and patch references, see: - [Issue: HTTP request node fails with remote_url](https://github.com/langgenius/dify/issues/22977) - [PR: multipart/form-data boundary fix](https://github.com/langgenius/dify/pull/23903) - [Workaround discussion](https://github.com/langgenius/dify/issues/24089#issuecomment-3195342324) <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/1bb88aeb-a657-4b8f-9fca-73f3a2526ab2?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/1bb88aeb-a657-4b8f-9fca-73f3a2526ab2?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/1bb88aeb-a657-4b8f-9fca-73f3a2526ab2?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/1bb88aeb-a657-4b8f-9fca-73f3a2526ab2?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/1bb88aeb-a657-4b8f-9fca-73f3a2526ab2?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/1bb88aeb-a657-4b8f-9fca-73f3a2526ab2?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/1bb88aeb-a657-4b8f-9fca-73f3a2526ab2?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/24292)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#16329