github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-03-10 15:54:15 -05:00
Code Issues 308 Packages Projects Releases 100 Wiki Activity

issue: RAG_ALLOWED_FILE_EXTENSIONS is too rigid and doesn't support all filetypes in accordance to chosen Content Extraction Engine #5473

New Issue
Open
opened 2025-11-11 16:21:55 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2025-11-11 16:21:55 -06:00
Owner
Copy Link

Originally created by @Hisma on GitHub (Jun 7, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker Compose

Open WebUI Version

0.6.13

Operating System

Ubuntu 24.04

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation.

Expected Behavior

  • All image types (.png, .jpg, etc.) should be able to be uploaded to a RAG knowledgebase when using a Content Extraction Engine that supports image OCR (e.g. datalab_marker - but this bug applies to all engines except external)
  • The empty whitelist Allowed File Extensions should truly mean “allow all file types,” or at minimum auto-whitelist those supported by the chosen engine.

Actual Behavior

  • Add to Knowledge (POST /api/v1/knowledge/{id}/file/add) returns 400 BAD REQUEST when adding an image/* MIME type, for any Document Extraction Engine other than external.

Steps to Reproduce

Environment

  • Host OS: Ubuntu 24.04
  • Docker: 27.4.1
  • Docker Compose
  open-webui:
    image: ghcr.io/open-webui/open-webui:cuda
    container_name: open-webui
    volumes:
      - /home/hisma/docker/owui:/app/backend/data
    depends_on:
      - ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ports:
      - ${OPEN_WEBUI_PORT-3000}:8080
    environment:
      - 'OLLAMA_BASE_URL=http://ollama:11434'
      - host.docker.internal:host-gateway
    restart: unless-stopped
    networks:
      - docker_default
  • Content Extraction Engine: datalab_marker (configured in UI in Document Settings)

Steps to reproduce

  1. Start Open WebUI with the above Docker setup.
  2. In UI, select **Settings → Admin Settings → Documents → Choose any Content Extraction Engine other than external **, click Save.
  3. Create or select an existing knowledge base.
  4. Click “Add File” → try to upload an image file
  5. Observe Add to Knowledge returns HTTP 400.

Docker Log

2025-06-07T02:37:29.177589670Z 2025-06-07 02:37:29.177 | INFO     | open_webui.routers.files:upload_file:94 - file.content_type: image/png - {}
2025-06-07T02:37:29.230187980Z 2025-06-07 02:37:29.229 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.0.213:51476 - "POST /api/v1/files/ HTTP/1.1" 200 - {}
2025-06-07T02:37:29.277926144Z 2025-06-07 02:37:29.277 | INFO     | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.0.213:51476 - "POST /api/v1/knowledge/352c958f-7686-429f-a187-b970eaf3302d/file/add HTTP/1.1" 400 - {}

Problematic Code Snippet

In backend/open_webui/routers/files.py around line 171, the engine-based logic currently looks like this:

elif (not file.content_type.startswith(("image/", "video/"))) or (
    request.app.state.config.CONTENT_EXTRACTION_ENGINE == "external"
):
    process_file(request, ProcessFileForm(file_id=id), user=user)

This means in open_webui/routers/retrieval.py, images and videos are only passed to process_file() when the engine equals "external". This hard-codes a block/allow rule for image & video files based on the engine name, rather than aligning the whitelist with the actual capabilities of the chosen OCR engine.

I edited that conditional logic referenced above from external to datalab_marker, and successfully uploaded an image, which proves this is where the problematic code lies.

Suggested Fixes

  1. Make RAG_ALLOWED_FILE_EXTENSIONS dynamic based on the file types the selected Content Extraction Engine actually supports, for example: datalab_marker has a mime_map that lists supported MIME types defined in the retrieval/datalab_marker.py file. Each loader would need a mime_map that's specific to that loader.
  2. If option 1 is too tedious, just make RAG_ALLOWED_FILE_EXTENSIONS truly allow all file types by default when left empty (including video/image/audio/etc), and enable the end user to white list file types manually via "Allowed File Extensions" option, without any pre-existing restrictions. If the selected engine encounters an error trying to upload a file to knowledge, return a generic "file type not supported" message.

Either option will allow users to upload any file type that their chosen OCR engine actually supports.

Originally created by @Hisma on GitHub (Jun 7, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker Compose ### Open WebUI Version 0.6.13 ### Operating System Ubuntu 24.04 ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. ### Expected Behavior * All image types (`.png`, `.jpg`, etc.) should be able to be uploaded to a RAG knowledgebase when using a `Content Extraction Engine` that supports image OCR (e.g. `datalab_marker` - but this bug applies to all engines except `external`) * The empty whitelist `Allowed File Extensions` should truly mean “allow all file types,” or at minimum auto-whitelist those supported by the chosen engine. ### Actual Behavior * Add to Knowledge (POST /api/v1/knowledge/{id}/file/add) returns **400 BAD REQUEST** when adding an `image/*` MIME type, for any Document Extraction Engine other than `external`. ### Steps to Reproduce ### Environment * **Host OS**: Ubuntu 24.04 * **Docker**: 27.4.1 * **Docker Compose** ```yaml open-webui: image: ghcr.io/open-webui/open-webui:cuda container_name: open-webui volumes: - /home/hisma/docker/owui:/app/backend/data depends_on: - ollama deploy: resources: reservations: devices: - driver: nvidia count: all capabilities: [gpu] ports: - ${OPEN_WEBUI_PORT-3000}:8080 environment: - 'OLLAMA_BASE_URL=http://ollama:11434' - host.docker.internal:host-gateway restart: unless-stopped networks: - docker_default ``` * **Content Extraction Engine**: `datalab_marker` (configured in UI in `Document Settings`) --- ### Steps to reproduce 1. **Start** Open WebUI with the above Docker setup. 2. **In UI**, select **Settings → Admin Settings → Documents → Choose any Content Extraction Engine other than `external` **, click **Save**. 3. **Create** or select an existing knowledge base. 4. **Click** “Add File” → try to upload an image file 5. **Observe** **Add to Knowledge** returns HTTP 400. ### Docker Log ``` 2025-06-07T02:37:29.177589670Z 2025-06-07 02:37:29.177 | INFO | open_webui.routers.files:upload_file:94 - file.content_type: image/png - {} 2025-06-07T02:37:29.230187980Z 2025-06-07 02:37:29.229 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.0.213:51476 - "POST /api/v1/files/ HTTP/1.1" 200 - {} 2025-06-07T02:37:29.277926144Z 2025-06-07 02:37:29.277 | INFO | uvicorn.protocols.http.httptools_impl:send:476 - 192.168.0.213:51476 - "POST /api/v1/knowledge/352c958f-7686-429f-a187-b970eaf3302d/file/add HTTP/1.1" 400 - {} ``` ### Problematic Code Snippet In **`backend/open_webui/routers/files.py`** around line 171, the engine-based logic currently looks like this: ```python elif (not file.content_type.startswith(("image/", "video/"))) or ( request.app.state.config.CONTENT_EXTRACTION_ENGINE == "external" ): process_file(request, ProcessFileForm(file_id=id), user=user) ``` This means in **`open_webui/routers/retrieval.py`**, images and videos are only passed to `process_file()` when the engine equals `"external"`. This hard-codes a block/allow rule for image & video files based on the engine name, rather than aligning the whitelist with the actual capabilities of the chosen OCR engine. I edited that conditional logic referenced above from `external` to `datalab_marker`, and successfully uploaded an image, which proves this is where the problematic code lies. ### Suggested Fixes 1. Make `RAG_ALLOWED_FILE_EXTENSIONS` **dynamic** based on the file types the selected **Content Extraction Engine** actually supports, for example: `datalab_marker` has a `mime_map` that lists supported MIME types defined in the `retrieval/datalab_marker.py` file. Each loader would need a `mime_map` that's specific to that loader. 2. If option 1 is too tedious, just make `RAG_ALLOWED_FILE_EXTENSIONS` truly allow all file types by default when left empty (including video/image/audio/etc), and enable the end user to white list file types manually via "Allowed File Extensions" option, without any pre-existing restrictions. If the selected engine encounters an error trying to upload a file to knowledge, return a generic "file type not supported" message. Either option will allow users to upload any file type that their chosen OCR engine actually supports.
GiteaMirror added the bug label 2025-11-11 16:21:55 -06:00
GiteaMirror commented 2025-11-11 16:21:56 -06:00
Author
Owner
Copy Link

@licaon-kter commented on GitHub (Jul 3, 2025):

Having the same issue with Tika, it can OCR pictures but... open-webui rejects these file right away.

@licaon-kter commented on GitHub (Jul 3, 2025): Having the same issue with Tika, it can OCR pictures but... open-webui rejects these file right away.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#5473
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?