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]

The issue was resolved without modifying the source code by adding a fixed boundary to the schema definition.

Below is a portion of my FastAPI code along with the schema definition:

TEMP_DIR = "./tmp"
DEFAULT_CHUNK_SIZE_SECONDS = 60  # Default chunk size in seconds

@app.post("/transcribe/")
async def transcribe_audio(
    request: Request,
    file: UploadFile = File(...),
    chunk_size: int = Query(DEFAULT_CHUNK_SIZE_SECONDS, ge=1, le=300)
):
    os.makedirs(TEMP_DIR, exist_ok=True)
    
    timestamp = datetime.now().strftime("%Y%m%d%H%M%S%f")
    unique_filename = f"{timestamp}_{file.filename}"
    filepath = os.path.join(TEMP_DIR, unique_filename)
    
    try:
        with open(filepath, "wb") as buffer:
            shutil.copyfileobj(file.file, buffer)
        
        if not os.path.exists(filepath):
            raise HTTPException(status_code=400, detail="File does not exist")

        return await process_and_transcribe_audio(filepath, chunk_size)

    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

{
    "openapi": "3.1.0",
    "info": {
      "title": "FastAPI",
      "version": "0.1.0"
    },
    "servers": [
        {
          "url": "http://example.com:9996"
        }
      ],
    "paths": {
      "/transcribe/": {
        "post": {
          "summary": "Transcribe Audio",
          "operationId": "stt_file",
          "parameters": [
            {
              "name": "chunk_size",
              "in": "query",
              "required": false,
              "schema": {
                "type": "integer",
                "maximum": 300,
                "minimum": 1,
                "default": 60,
                "title": "Chunk Size"
              }
            }
          ],
          "requestBody": {
            "required": true,
            "content": {
              "multipart/form-data; boundary=----WebKitFormBoundarydzemBAPhdeDfTCfR:": {
                "schema": {
                  "$ref": "#/components/schemas/Body_transcribe_audio_transcribe__post"
                }
              }
            }
          },
          "responses": {
            "200": {
              "description": "Successful Response",
              "content": {
                "application/json": {
                  "schema": {
  
                  }
                }
              }
            },
...
    "components": {
      "schemas": {
        "Body_transcribe_audio_transcribe__post": {
          "properties": {
            "file": {
              "type": "string",
              "format": "binary",
              "title": "File"
            }
          },
          "type": "object",
          "required": [
            "file"
          ],
          "title": "Body_transcribe_audio_transcribe__post"
        },
...

[monchchang]

I tried this and encountered a 'reached max retries' error, with the Squid logs showing a TCP_MISS_ABORTED/000 error. However, when I deployed a new Dify on another PC, the issue was resolved, so I believe it might be related to the network. I truly appreciate your help!

[monchchang]

I found that the 'add boundary' method works the first time I upload a file and run the workflow, but it keeps getting a TCP_MISS_ABORTED/000 error when I upload a new file, until I restart the Dify Docker containers. I'm not sure what causes this.

[zolgear]

The same error occurred in WSL2.
The issue was related to ssrf (ubuntu/squid), where a cache size limitation caused the error TCP_MISS_ABORTED/00.
Adding the following line to the end of dify/docker/ssrf_proxy/squid.conf.template resolved the problem:

client_request_buffer_max_size 5 MB

This issue did not occur on a non-virtualized Ubuntu environment.

[monchchang]

This solution works perfefctly, many thanks!

[svcvit]

Is it possible to mount the upload folder from the API container onto the sandbox and add a relative path in the File object? This way, the sandbox can access files based on the path. The main goal is to use the files in the code node, which would also avoid issues with url and remote_url.

[svcvit]

Personally, I believe that uploaded files should be supported as much as possible by Dify's own nodes, especially for highly flexible nodes like the sandbox. If these nodes can access files, it opens up much greater possibilities.

On the other hand, providing download links for files shouldn't be a focus for Dify, as there are many other services dedicated to file upload and download. If users simply need download links, they can use services like S3, which would be more appropriate.

[hjlarry]

the uploaded files may not in the API container, it depends on STORAGE_TYPE of .env. so maybe transfer file content to sandbox is the only way?

[svcvit]

In local mode, the uploaded file directory is automatically mounted to two containers by default, providing an elegant and efficient solution that avoids duplicate file storage.
For users in other modes, the sandbox can be used to install dependencies (e.g., S3), enabling file downloads based on the path.

An alternative solution I previously considered involved starting an HTTP service in the sandbox to receive files, using the updated Custom Tool to transfer them. However, this approach adds complexity by requiring logic to determine whether the sandbox needs the files. As such, the path based approach is simpler, more efficient, and widely applicable.

[XiaoLey]

In my humble opinion, the current issue lies in the inability of the "url" field in the file type to be correctly output. Regardless of how the file is utilized within nodes—for instance, whether it bypasses url transmission in the future or a new node is introduced to handle it—this does not justify the current failure to properly recognize the "url" field.

Moreover, if the "url" field is indeed necessary, there are, in my view, only two viable options: either use dynamic urls (which could involve temporary URLs or other methods of generation) or use static urls.

To put it simply, if there is no intention to provide a urls externally, this field should not exist to confuse users. Otherwise, it should hold meaningful data rather than remaining empty or null as it does now.

In fact, this opinion was previously expressed by @hjlarry , but it seems to have been overlooked. The team's focus has remained on finding ways to retrieve the file itself, rather than examining whether the fields provided in the file type are functioning as expected. We should not continue offering a malfunctioning field. If it remains broken, we should either fix it immediately or remove it altogether.

[laipz8200]

I agree. We haven't done this yet because in some cases, users of the workflow need this URL to access the generated files. Once we resolve this issue, we plan to remove this field.

[XiaoLey]

I agree. We haven't done this yet because in some cases, users of the workflow need this URL to access the generated files. Once we resolve this issue, we plan to remove this field.

How about merging #10513 first and changing the title to 'temporary fix for unavailable to retrieve URL from file error'?

[laipz8200]

If we use this way, it will be a huge breaking change for all workflows related to this feature when we remove it.

[XiaoLey]

Perhaps you are right, I have not come up with any method that is more suitable for everyone's usage.

Actually, I also want to hear everyone's suggestions.

Looking forward to your decisions and results. 😃

[JimmySunCreater]

I also meet the same problem, I upload the data to aws s3, I think it would be better to show the url to users and make users can configure the time of the pre-signed url.
What's more, is there any work-arounds to get the path? I'm handling the video data.

[itzhoujun]

so we how to get file content?

[rv192]

Actually, after I receive pictures or documents, I need to call a third-party API through Dify, and when I transmit these files to the third-party API, I actually have no way to operate:

1. The API may provide two ways of file transmission: url/base64
2. I need to upload the file and get a url, but I currently cannot get the file's context information to operate;
3. Convert the file to base64, but I cannot get the file's context information to operate;
4. I saw file.url in the log, and I can access it through the browser, but I still can't get this file.url in the workflow

[hjlarry]

a temporary solution is use a custom tool, start another HTTP service to receive the file and other context information.
I think this will be resolve in the 1.0 version.