github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 23:21:44 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[PR #11636] [MERGED] fix: audio api endpoint filetype check #126426

New Issue
Closed
opened 2026-05-21 07:38:38 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-21 07:38:38 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/11636
Author: @OliveiraHermogenes
Created: 3/13/2025
Status: ✅ Merged
Merged: 3/14/2025
Merged by: @tjbck

Base: dev ← Head: fix-api-audio-mimetype-check

📝 Commits (1)

  • e936d7b fix: audio api endpoint filetype check

📊 Changes

1 file changed (+3 additions, -1 deletions)

View changed files

📝 backend/open_webui/routers/audio.py (+3 -1)

📄 Description

Pull Request Checklist

Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.

Fixes #11426

Before submitting, make sure you've checked the following:

  • Target branch: Please verify that the pull request targets the dev branch.
  • Description: Provide a concise description of the changes made in this pull request.
  • Changelog: Ensure a changelog entry following the format of Keep a Changelog is added at the bottom of the PR description.
  • Documentation: Have you updated relevant documentation Open WebUI Docs, or other documentation sources?

Not applicable.

  • Dependencies: Are there any new dependencies? Have you updated the dependency versions in the documentation? Not Applicable

Not applicable.

  • Testing: Have you written and run sufficient tests for validating the changes?

Preexisting tests against /api/audio endpoints, if any, still apply.

  • Code review: Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards?
  • Prefix: To cleary categorize this pull request, prefix the pull request title, using one of the following:
    • BREAKING CHANGE: Significant changes that may affect compatibility
    • build: Changes that affect the build system or external dependencies
    • ci: Changes to our continuous integration processes or workflows
    • chore: Refactor, cleanup, or other non-functional code changes
    • docs: Documentation update or addition
    • feat: Introduces a new feature or enhancement to the codebase
    • fix: Bug fix or error correction
    • i18n: Internationalization or localization changes
    • perf: Performance improvement
    • refactor: Code restructuring for better maintainability, readability, or scalability
    • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
    • test: Adding missing tests or correcting existing tests
    • WIP: Work in progress, a temporary label for incomplete or ongoing work

Changelog Entry

Description

  • [Concisely describe the changes made in this pull request, including any relevant motivation and impact (e.g., fixing a bug, adding a feature, or improving performance)]

See #11426 for more context. A more technical rationale for the changes follow.

RFC2046 allows the Content-Type field to have additional parameters after the main type/subtype information (Section 1).

Following RFC4281, many applications put codec information inside parameters in the Content-Type. This is especially common for formats that support many codecs, such as Ogg (RFC5334, Section 4).

The /api/audio/transcriptions endpoint is currently rejecting files that contain parameters in the Content-Type field with a bad request error.

This commit changes the current check in order to accept any Content-Type field that begins with a supported type/subtype as listed in the supported_filetypes tuple.

Since Content-Type here is provided by the user, I believe this check is meant to prevent honest mistakes, like posting a PDF to an audio processing endpoint, not as a security measure against possibly malicious use. Therefore, I think it's OK not to validate the rest of the field.

Fixed

  • 🎤 Audio API Issue: Fixed an issue where the audio API endpoint was throwing an error for some files with a valid content-type.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/open-webui/pull/11636 **Author:** [@OliveiraHermogenes](https://github.com/OliveiraHermogenes) **Created:** 3/13/2025 **Status:** ✅ Merged **Merged:** 3/14/2025 **Merged by:** [@tjbck](https://github.com/tjbck) **Base:** `dev` ← **Head:** `fix-api-audio-mimetype-check` --- ### 📝 Commits (1) - [`e936d7b`](https://github.com/open-webui/open-webui/commit/e936d7b53d4828eb3a8080c914f88f0f5cd7b0b7) fix: audio api endpoint filetype check ### 📊 Changes **1 file changed** (+3 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/routers/audio.py` (+3 -1) </details> ### 📄 Description # Pull Request Checklist ### Note to first-time contributors: Please open a discussion post in [Discussions](https://github.com/open-webui/open-webui/discussions) and describe your changes before submitting a pull request. Fixes #11426 **Before submitting, make sure you've checked the following:** - [X] **Target branch:** Please verify that the pull request targets the `dev` branch. - [X] **Description:** Provide a concise description of the changes made in this pull request. - [X] **Changelog:** Ensure a changelog entry following the format of [Keep a Changelog](https://keepachangelog.com/) is added at the bottom of the PR description. - [X] **Documentation:** Have you updated relevant documentation [Open WebUI Docs](https://github.com/open-webui/docs), or other documentation sources? Not applicable. - [X] **Dependencies:** Are there any new dependencies? Have you updated the dependency versions in the documentation? **Not Applicable** Not applicable. - [X] **Testing:** Have you written and run sufficient tests for validating the changes? Preexisting tests against `/api/audio` endpoints, if any, still apply. - [X] **Code review:** Have you performed a self-review of your code, addressing any coding standard issues and ensuring adherence to the project's coding standards? - [X] **Prefix:** To cleary categorize this pull request, prefix the pull request title, using one of the following: - **BREAKING CHANGE**: Significant changes that may affect compatibility - **build**: Changes that affect the build system or external dependencies - **ci**: Changes to our continuous integration processes or workflows - **chore**: Refactor, cleanup, or other non-functional code changes - **docs**: Documentation update or addition - **feat**: Introduces a new feature or enhancement to the codebase - **fix**: Bug fix or error correction - **i18n**: Internationalization or localization changes - **perf**: Performance improvement - **refactor**: Code restructuring for better maintainability, readability, or scalability - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.) - **test**: Adding missing tests or correcting existing tests - **WIP**: Work in progress, a temporary label for incomplete or ongoing work # Changelog Entry ### Description - [Concisely describe the changes made in this pull request, including any relevant motivation and impact (e.g., fixing a bug, adding a feature, or improving performance)] See #11426 for more context. A more technical rationale for the changes follow. RFC2046 allows the Content-Type field to have additional parameters after the main type/subtype information (Section 1). Following RFC4281, many applications put codec information inside parameters in the Content-Type. This is especially common for formats that support many codecs, such as Ogg (RFC5334, Section 4). The `/api/audio/transcriptions` endpoint is currently rejecting files that contain parameters in the Content-Type field with a bad request error. This commit changes the current check in order to accept any Content-Type field that begins with a supported type/subtype as listed in the `supported_filetypes` tuple. Since Content-Type here is provided by the user, I believe this check is meant to prevent honest mistakes, like posting a PDF to an audio processing endpoint, not as a security measure against possibly malicious use. Therefore, I think it's OK not to validate the rest of the field. ### Fixed - **🎤 Audio API Issue**: Fixed an issue where the audio API endpoint was throwing an error for some files with a valid content-type. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-21 07:38:38 -05:00
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 pull-request
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#126426
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?