langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Issue: mimetypes Module Fails to Detect MIME Types in Minimal Docker Images #8258

New Issue
Closed
opened 2026-02-21 18:24:44 -05:00 by yindo · 5 comments
yindo commented 2026-02-21 18:24:44 -05:00
Owner
Copy Link
Copy Source

Originally created by @yjc980121 on GitHub (Feb 13, 2025).

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.15.3

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The mimetypes.guess_type() function in Python is used to guess the MIME type of a file based on its extension. However, when running in minimal Docker images such as python:3.12-alpine or python:3.12-slim, the function fails to accurately detect MIME types due to the absence of the /etc/mime.types file. This file is essential for the mimetypes module to provide accurate results.
Reproduction Steps
Run the following Python code in a minimal Docker image (e.g., python:3.12-alpine or python:3.12-slim):

import os
import mimetypes

def guesstype(filename):
    print(f'filename: {filename}')
    mime_type = mimetypes.guess_type(filename)[0] or ""
    print(f'mime_type: {mime_type}')

guesstype("eb7215b51eae490b84b6f7f0646df2c4.docx")

# Check known files
for file in mimetypes.knownfiles:
    print(f'file: {file} {os.path.exists(file)}')

Observe the output. The MIME type detection will be incorrect, and the /etc/mime.types file will not exist.

✔️ Expected Behavior

The mimetypes.guess_type() function should accurately detect the MIME type of a file based on its extension, even in minimal Docker images.
Actual Behavior
In minimal Docker images, the /etc/mime.types file is missing, leading to incorrect MIME type detection. The function returns an empty string or an incorrect MIME type.

Possible Solutions
1.Use a Non-Minimal Docker Image
Switch to a non-minimal Docker image such as python:3.12, which includes the necessary /etc/mime.types file. This approach ensures accurate MIME type detection without additional configuration.

2.Map the /etc/mime.types File
If a minimal Docker image is preferred, the /etc/mime.types file from the host can be mapped to the container. This method does not require modifying the Docker image.
Prerequisites: Ensure that the /etc/mime.types file exists on the host. If it does not, it can be downloaded from a reliable source such as the Apache HTTP Server repository.

  1. Use the python-magic Library as a Fallback
    As an alternative, the python-magic library can be used. This library does not rely on the /etc/mime.types file and instead uses file signatures to determine MIME types.

  2. Copy and Initialize a Custom mime.types File
    For those who need to use a minimal Docker image and avoid mapping files, a custom mime.types file can be copied into the image and initialized using mimetypes.init().

Related Issues
#13285
#13146

❌ Actual Behavior

No response

Originally created by @yjc980121 on GitHub (Feb 13, 2025). ### Self Checks - [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 (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [x] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.15.3 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce The mimetypes.guess_type() function in Python is used to guess the MIME type of a file based on its extension. However, when running in minimal Docker images such as python:3.12-alpine or python:3.12-slim, the function fails to accurately detect MIME types due to the absence of the /etc/mime.types file. This file is essential for the mimetypes module to provide accurate results. Reproduction Steps Run the following Python code in a minimal Docker image (e.g., python:3.12-alpine or python:3.12-slim): ```python import os import mimetypes def guesstype(filename): print(f'filename: {filename}') mime_type = mimetypes.guess_type(filename)[0] or "" print(f'mime_type: {mime_type}') guesstype("eb7215b51eae490b84b6f7f0646df2c4.docx") # Check known files for file in mimetypes.knownfiles: print(f'file: {file} {os.path.exists(file)}') ``` Observe the output. The MIME type detection will be incorrect, and the /etc/mime.types file will not exist. ### ✔️ Expected Behavior The mimetypes.guess_type() function should accurately detect the MIME type of a file based on its extension, even in minimal Docker images. Actual Behavior In minimal Docker images, the /etc/mime.types file is missing, leading to incorrect MIME type detection. The function returns an empty string or an incorrect MIME type. Possible Solutions 1.Use a Non-Minimal Docker Image Switch to a non-minimal Docker image such as python:3.12, which includes the necessary /etc/mime.types file. This approach ensures accurate MIME type detection without additional configuration. 2.Map the /etc/mime.types File If a minimal Docker image is preferred, the /etc/mime.types file from the host can be mapped to the container. This method does not require modifying the Docker image. Prerequisites: Ensure that the /etc/mime.types file exists on the host. If it does not, it can be downloaded from a reliable source such as the Apache HTTP Server repository. 3. Use the python-magic Library as a Fallback As an alternative, the python-magic library can be used. This library does not rely on the /etc/mime.types file and instead uses file signatures to determine MIME types. 4. Copy and Initialize a Custom mime.types File For those who need to use a minimal Docker image and avoid mapping files, a custom mime.types file can be copied into the image and initialized using mimetypes.init(). Related Issues #13285 #13146 ### ❌ Actual Behavior _No response_
yindo closed this issue 2026-02-21 18:24:44 -05:00
yindo commented 2026-02-21 18:24:44 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Feb 13, 2025):

To address the issue of MIME type detection failing in minimal Docker images due to the absence of the /etc/mime.types file, you can consider the following solutions:

  1. Use a Non-Minimal Docker Image: Switch to a Docker image like python:3.12, which includes the necessary /etc/mime.types file. This ensures accurate MIME type detection without additional configuration.

  2. Map the /etc/mime.types File: If you prefer using a minimal Docker image, you can map the /etc/mime.types file from the host to the container. Ensure the file exists on the host, or download it from a reliable source like the Apache HTTP Server repository.

  3. Use the python-magic Library: This library can be used as a fallback for MIME type detection. It does not rely on the /etc/mime.types file and uses file signatures instead. This approach is already part of the Dify codebase for content-based MIME type detection [1].

  4. Copy and Initialize a Custom mime.types File: For those who need to use a minimal Docker image and avoid mapping files, you can copy a custom mime.types file into the image and initialize it using mimetypes.init().

These solutions should help ensure accurate MIME type detection in your Docker environment.

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Bug Report | Other

@dosubot[bot] commented on GitHub (Feb 13, 2025): <!-- Answer --> To address the issue of MIME type detection failing in minimal Docker images due to the absence of the `/etc/mime.types` file, you can consider the following solutions: 1. **Use a Non-Minimal Docker Image**: Switch to a Docker image like `python:3.12`, which includes the necessary `/etc/mime.types` file. This ensures accurate MIME type detection without additional configuration. 2. **Map the `/etc/mime.types` File**: If you prefer using a minimal Docker image, you can map the `/etc/mime.types` file from the host to the container. Ensure the file exists on the host, or download it from a reliable source like the Apache HTTP Server repository. 3. **Use the `python-magic` Library**: This library can be used as a fallback for MIME type detection. It does not rely on the `/etc/mime.types` file and uses file signatures instead. This approach is already part of the Dify codebase for content-based MIME type detection <sup>[[1]](https://github.com/langgenius/dify/issues/12551)</sup>. 4. **Copy and Initialize a Custom `mime.types` File**: For those who need to use a minimal Docker image and avoid mapping files, you can copy a custom `mime.types` file into the image and initialize it using `mimetypes.init()`. These solutions should help ensure accurate MIME type detection in your Docker environment. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/a510dd73-02dd-4ca7-b7b2-a5854a6c81b6?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/a510dd73-02dd-4ca7-b7b2-a5854a6c81b6?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/a510dd73-02dd-4ca7-b7b2-a5854a6c81b6?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/a510dd73-02dd-4ca7-b7b2-a5854a6c81b6?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/a510dd73-02dd-4ca7-b7b2-a5854a6c81b6?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/a510dd73-02dd-4ca7-b7b2-a5854a6c81b6?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/a510dd73-02dd-4ca7-b7b2-a5854a6c81b6?feedback_type=other)</sup>
yindo commented 2026-02-21 18:24:45 -05:00
Author
Owner
Copy Link
Copy Source

@kurokobo commented on GitHub (Feb 13, 2025):

This can be solved by installing specific apt package. My PR for this has been opened for a while: https://github.com/langgenius/dify/pull/13101

Will solve coflict later :)

@kurokobo commented on GitHub (Feb 13, 2025): This can be solved by installing specific apt package. My PR for this has been opened for a while: https://github.com/langgenius/dify/pull/13101 Will solve coflict later :)
yindo commented 2026-02-21 18:24:45 -05:00
Author
Owner
Copy Link
Copy Source

@yjc980121 commented on GitHub (Feb 14, 2025):

This can be solved by installing specific apt package. My PR for this has been opened for a while: #13101

Will solve coflict later :)

thanks, i found this package is better mime-support
in ubuntu ,run this command can found it

apt list| grep installed |grep mime

@yjc980121 commented on GitHub (Feb 14, 2025): > This can be solved by installing specific apt package. My PR for this has been opened for a while: [#13101](https://github.com/langgenius/dify/pull/13101) > > Will solve coflict later :) thanks, i found this package is better mime-support in ubuntu ,run this command can found it ` apt list| grep installed |grep mime `
yindo commented 2026-02-21 18:24:45 -05:00
Author
Owner
Copy Link
Copy Source

@kurokobo commented on GitHub (Feb 14, 2025):

This issue affects both main and plugins/beta branches.
I know that regardless of which branch this change is merged into, it will eventually be included in 1.0.0, but I wasn't sure which branch should take priority, so I created a PR for both branches:

It's okay to adopt just one of these PRs. Thanks!

@kurokobo commented on GitHub (Feb 14, 2025): This issue affects both `main` and `plugins/beta` branches. I know that regardless of which branch this change is merged into, it will eventually be included in 1.0.0, but I wasn't sure which branch should take priority, so I created a PR for both branches: - For `main` branch: https://github.com/langgenius/dify/pull/13752 - For `plugins/beta` branch: https://github.com/langgenius/dify/pull/13101 It's okay to adopt just one of these PRs. Thanks!
yindo commented 2026-02-21 18:24:45 -05:00
Author
Owner
Copy Link
Copy Source

@kurokobo commented on GitHub (Feb 14, 2025):

@yjc980121
The mime-support package was split into media-types and mailcap, and I think we don't need mailcap. So I add only media-types package in my PRs.

Refer to Debian Wiki:

The mime-support package (final version number: 3.66) was split into media-types and mailcap during the Bullseye release cycle.
https://wiki.debian.org/mime-support

@kurokobo commented on GitHub (Feb 14, 2025): @yjc980121 The mime-support package was split into [media-types](https://packages.debian.org/media-types) and [mailcap](https://packages.debian.org/mailcap), and I think we don't need mailcap. So I add only media-types package in my PRs. Refer to Debian Wiki: > The mime-support package ([final version number: 3.66](http://snapshot.debian.org/package/mime-support/3.66/)) was split into [media-types](https://packages.debian.org/media-types) and [mailcap](https://packages.debian.org/mailcap) during the Bullseye release cycle. > https://wiki.debian.org/mime-support
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#8258
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?