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>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 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)
e936d7bfix: 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:
devbranch.Not applicable.
Not applicable.
Preexisting tests against
/api/audioendpoints, if any, still apply.Changelog Entry
Description
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/transcriptionsendpoint 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_filetypestuple.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
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.