github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #14768] issue: RAG_ALLOWED_FILE_EXTENSIONS is too rigid and doesn't support all filetypes in accordance to chosen Content Extraction Engine #32889

New Issue
Open
opened 2026-04-25 06:44:38 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-25 06:44:38 -05:00
Owner
Copy Link

Originally created by @Hisma on GitHub (Jun 7, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14768

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). Original GitHub issue: https://github.com/open-webui/open-webui/issues/14768 ### 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 2026-04-25 06:44:38 -05:00
GiteaMirror commented 2026-04-25 06:44:39 -05: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.

<!-- gh-comment-id:3031805335 --> @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.
GiteaMirror commented 2026-04-25 06:44:40 -05:00
Author
Owner
Copy Link

@Ark-Levy commented on GitHub (Feb 5, 2026):

Hi, I'm also affected by this specifically with the Google Drive Picker integration.

When ALLOWED_FILE_EXTENSIONS is set, Google Drive imports always fail because Google Workspace files (Docs, Sheets,
etc.) come without a file extension in their name. So the backend gets an empty extension and rejects the upload.

Right now users have to disable all file extension filters before importing from Google Drive, which is not great UX.

Is there a fix planned? Happy to submit a PR if needed.

<!-- gh-comment-id:3852405385 --> @Ark-Levy commented on GitHub (Feb 5, 2026): Hi, I'm also affected by this specifically with the Google Drive Picker integration. When ALLOWED_FILE_EXTENSIONS is set, Google Drive imports always fail because Google Workspace files (Docs, Sheets, etc.) come without a file extension in their name. So the backend gets an empty extension and rejects the upload. Right now users have to disable all file extension filters before importing from Google Drive, which is not great UX. Is there a fix planned? Happy to submit a PR if needed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
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#32889
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?