Should we allow access to the signed URL in the workflow?

[hjlarry]

Steps to reproduce

1. add a start node, list operator node, and an end node.
2. upload any local file in the start node, in the end node get list operator node's url

✔️ Expected Behavior

get the correct file url

❌ Actual Behavior

not get the correct value

[hjlarry]

the remote_url and the url attr of File is not so much clear

I think the remote_url attr is necessary, for example, I use a tool generate an image, use another tool edit or vectorize the image. directly transfer the first tool response url to the second tool is more efficient

[tsugitta]

Are there any workarounds?

[laipz8200]

I need to provide an explanation regarding this issue: currently, File.url refers to the remote_url attribute shown in the logs. The url in the logs is a signed, short-lived temporary address, and it currently cannot be referenced within the Workflow.

[laipz8200]

Now, the question is how we should handle these URLs that will expire soon. They might appear in the current chat, show up in logs, and users could even notice that these addresses quickly become inaccessible within the same conversation (if the chat lasts long enough).

I don’t think opening temporary signed URLs is a very elegant solution. We need to find a more practical way to allow users to access the files.

[XiaoLey]

I discovered that the _to_url function in the file_manager.py file generates a different temporary URL each time it's called. I tested this and found that if you use _to_url to get a URL, the same file passing through two different nodes will have different URLs for each node. In other words, using _to_url ensures that each node gets a unique temporary URL with its own expiration time.

Of course, if there's no intention to use the temporary URLs anymore, then my approach would indeed no longer be applicable. However, if we plan to continue using temporary URLs, I believe that no node should process a file for longer than the file URL's expiration time.

[laipz8200]

I hope to avoid using temporary URLs. In fact, if you look at how we handle files in the answer node, it implements a method of updating signatures during queries. This ensures that files in the logs can be accessed correctly, something that allowing users to access temporary URLs does not achieve.

[fungxu]

can you tell us how to use the _to_url function in "URL1" test ? I try to pass the firt object in "列表操作" output , i got some "File Object is not serializable Error"

[hjlarry]

can you tell us how to use the _to_url function in "URL1" test ? I try to pass the firt object in "列表操作" output , i got some "File Object is not serializable Error"

this error seems you draft run single node? try run whole workflow again

[fungxu]

i run the whole workflow, just got "Object of type File is not JSON serializable".

I just pass the file object to "模板转换" node.

[laipz8200]

@fungxu You're right, the Template node does not support File type yet.

[hjlarry]

1. If no node can access the temporary url, we should hide it in all node outputs.
2. Using remote_url instead of url in the frontend can reduce misunderstandings.
3. For developers, it's convenient enough to get file content or send http request with file content.
4. If some user required to use a long term url, we can add tools or copy the file to sandbox for share.
5. Currently, url in the previous node's output but not in the current node may confuse user like a bug.

[laipz8200]

@zolgear Starting from version 0.10.0, we’ve supported receiving file and files type parameters in build-in tools. This means you can get a File object/array in your tool and use file_manager.download to access the actual file content.

Is there a example ?

Check #10695

[AnoyiX]

is there a 代码执行 node example to get file content?

[laipz8200]

is there a 代码执行 node example to get file content?

No, that is not allowed.

[zolgear]

Thanks for the guidance!

Check #10695

I reviewed the pull request, and I understand now that this should be built as an API extension rather than as a custom tool.

Referring to #10694, I initially tried using "Code Execution," "List Operators," and "Tools - Custom Tool" nodes instead of the DOC EXTRACTOR node. However, none of these nodes seem to provide access to variables other than url.

If it were possible to access {x} sys.files Array[file] within a custom tool (ref #9322), I could avoid using temporary URLs mid-workflow, but I realize this is unrelated to the current "answer" output.

[laipz8200]

Thanks for the guidance!

Check #10695

I reviewed the pull request, and I understand now that this should be built as an API extension rather than as a custom tool.

Referring to #10694, I initially tried using "Code Execution," "List Operators," and "Tools - Custom Tool" nodes instead of the DOC EXTRACTOR node. However, none of these nodes seem to provide access to variables other than url.

If it were possible to access {x} sys.files Array[file] within a custom tool (ref #9322), I could avoid using temporary URLs mid-workflow, but I realize this is unrelated to the current "answer" output.

It’s my oversight; I was referring to built-in tools. For modes that rely on the network, we are not yet ready to support the File type.

[JavanTang]

In a real application, this function is important. For example, although Dify has word parsing capabilities, it does not sufficiently support some applications, such as splitting chapters using Python-doc tools. Therefore, at least one method should be provided to help users customize the process for their files. Alternatively, there could be a way for users to obtain the file path, which seems more reasonable for processing their uploaded files.

[laipz8200]

Currently, files can be used in DocumentExtractor and Built-in Tools, but they are not supported in OpenAPI-based Custom Tools.

For Custom Tools, an alternative is to use the HTTP Request Node in Workflow or Chatflow to send files to your own service. However, this approach cannot be used within an Agent.

It’s not necessary for every node to support file inputs, as not all nodes are designed to handle files.

[zolgear]

Clear and helpful information!

The "Send File" feature in the "HTTP Request" node (https://docs.dify.ai/guides/workflow/node/http-request) was overlooked. Wrapping it in a workflow made it possible to integrate the STT workflow, functioning like a custom tool.

[JavanTang]

I seem to understand that it means splitting the workflow and the file manager, but I want to use a durable file. Does this mean I need to build a file manager and send the file here? Is that correct?

[laipz8200]

The Custom Tool now supports file handling, thanks to @hjlarry in #10796. Give it a try! (in the main branch)

[zolgear]

File sending was successfully defined in the workflow.

However, execution failed because the Content-Type header was missing the boundary:

Error: Request failed with status code 400 and {"detail":"Missing boundary in multipart."}

Would a more detailed report be helpful?

---

Error :

POST /transcribe/?chunk_size=60 HTTP/1.1
Host: **********:5051
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
User-Agent: python-httpx/0.27.2
Content-Type: multipart/form-data
Content-Length: 767607

FastAPI Swagger :

POST /transcribe/?chunk_size=60 HTTP/1.1
Host: **********:5051
Connection: keep-alive
Content-Length: 767619
accept: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36
Content-Type: multipart/form-data; boundary=----WebKitFormBoundarydzemBAPhdeDfTCfR
...

[on_tool_error] Error: Request failed with status code 400 and {"detail":"Missing boundary in multipart."}
2024-11-20 18:05:22.582 ERROR [Thread-1245 (_generate_worker)] [node.py:72] - Node 1732090715560 failed to run
Traceback (most recent call last):
  File "/home/docker/dify.dev/api/core/workflow/nodes/base/node.py", line 70, in run
    result = self._run()
             ^^^^^^^^^^^
  File "/home/docker/dify.dev/api/core/workflow/nodes/tool/tool_node.py", line 76, in _run
    messages = ToolEngine.workflow_invoke(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/docker/dify.dev/api/core/tools/tool_engine.py", line 154, in workflow_invoke
    raise e
  File "/home/docker/dify.dev/api/core/tools/tool_engine.py", line 142, in workflow_invoke
    response = tool.invoke(user_id=user_id, tool_parameters=tool_parameters)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/docker/dify.dev/api/core/tools/tool/tool.py", line 209, in invoke
    result = self._invoke(
             ^^^^^^^^^^^^^
  File "/home/docker/dify.dev/api/core/tools/tool/api_tool.py", line 301, in _invoke
    response = self.validate_and_parse_response(response)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/docker/dify.dev/api/core/tools/tool/api_tool.py", line 107, in validate_and_parse_response
    raise ToolInvokeError(f"Request failed with status code {response.status_code} and {response.text}")
core.tools.errors.ToolInvokeError: Request failed with status code 400 and {"detail":"Missing boundary in multipart."}

[hjlarry]

the boundary is always be auto set by browser. Here we use httpx to send a request, if you send files without Content-Type in your request headers, httpx will help you generate both Content-Type and boundary . But if you set it, httpx will not overwrite it. So try to remove the Content-Type

[zolgear]

Commented out the following line:

dify/api/core/tools/tool/api_tool.py

Line 165 in af53e2b

headers["Content-Type"] = content_type

It's a temporary fix, but it worked.
Thanks!

[hjlarry]

or just modify the schema maybe works too? replace multipart/form-data: to multipart/form-data; boundary=----WebKitFormBoundarydzemBAPhdeDfTCfR:

[zolgear]

It worked perfectly!