[PR #24837] [CLOSED] fix(images): accept non-standard Content-Type in image generation responses #115193

New Issue

GiteaMirror · 2026-05-18T16:08:47-05:00

GiteaMirror commented

2026-05-18 16:08:47 -05:00

📋 Pull Request Information

Original PR: https://github.com/open-webui/open-webui/pull/24837
Author: @first-it-consulting
Created: 5/17/2026
Status: ❌ Closed

Base: main ← Head: fix/image-generation-aiohttp-content-type-ndjson

📝 Commits (1)

e0750fe fix(images): pass content_type=None to r.json() to accept non-standard MIME types

📊 Changes

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

View changed files

📝 backend/open_webui/routers/images.py (+5 -5)

📄 Description

Summary

aiohttp's ClientResponse.json() validates the Content-Type header against application/json by default and raises ContentTypeError for any other value. This silently breaks image generation for users whose backend returns a different but valid content type.

The most common case: Ollama's OpenAI-compatible /v1/images/generations endpoint returns Content-Type: application/x-ndjson (chunked streaming header) even though the response body is a single, complete JSON object. Every image generation request via Ollama fails with:

aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: application/x-ndjson'

The same issue can affect any other backend that returns valid JSON with a non-standard MIME type (e.g. text/plain, application/octet-stream).

Root Cause

aiohttp.ClientResponse.json() accepts a content_type parameter that defaults to "application/json". When the server returns any other MIME type, aiohttp raises ContentTypeError after successfully reading the response body — the JSON is already there, it just never gets parsed.

Fix

Pass content_type=None to every r.json() call that handles an image generation or editing response. This is the documented aiohttp pattern for skipping the content-type check while keeping all other parsing behaviour identical.

# Before
res = await r.json()

# After
res = await r.json(content_type=None)

Five call sites are affected: image_generations (openai, gemini, automatic1111 engines) and image_edits (openai, gemini engines).

Testing

Verified against Ollama v0.21.2 (/v1/images/generations) with model x/flux2-klein:latest:

Without fix: ContentTypeError raised immediately after generation completes
With fix: response parsed correctly, b64_json image returned as expected

The change is backwards-compatible — providers returning application/json are unaffected.

#20848 — Ollama image generation connection request
#4915 — Ollama sends Content-Type: application/x-ndjson

_{🔄 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/24837 **Author:** [@first-it-consulting](https://github.com/first-it-consulting) **Created:** 5/17/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/image-generation-aiohttp-content-type-ndjson` --- ### 📝 Commits (1) - [`e0750fe`](https://github.com/open-webui/open-webui/commit/e0750fed7b0646029e6cea7641b360c3d3c11d81) fix(images): pass content_type=None to r.json() to accept non-standard MIME types ### 📊 Changes **1 file changed** (+5 additions, -5 deletions) <details> <summary>View changed files</summary> 📝 `backend/open_webui/routers/images.py` (+5 -5) </details> ### 📄 Description ## Summary `aiohttp`'s `ClientResponse.json()` validates the `Content-Type` header against `application/json` by default and raises `ContentTypeError` for any other value. This silently breaks image generation for users whose backend returns a different but valid content type. The most common case: **Ollama's OpenAI-compatible `/v1/images/generations` endpoint returns `Content-Type: application/x-ndjson`** (chunked streaming header) even though the response body is a single, complete JSON object. Every image generation request via Ollama fails with: ``` aiohttp.client_exceptions.ContentTypeError: 0, message='Attempt to decode JSON with unexpected mimetype: application/x-ndjson' ``` The same issue can affect any other backend that returns valid JSON with a non-standard MIME type (e.g. `text/plain`, `application/octet-stream`). ## Root Cause `aiohttp.ClientResponse.json()` accepts a `content_type` parameter that defaults to `"application/json"`. When the server returns any other MIME type, aiohttp raises `ContentTypeError` **after** successfully reading the response body — the JSON is already there, it just never gets parsed. ## Fix Pass `content_type=None` to every `r.json()` call that handles an image generation or editing response. This is the [documented aiohttp pattern](https://docs.aiohttp.org/en/stable/client_reference.html#aiohttp.ClientResponse.json) for skipping the content-type check while keeping all other parsing behaviour identical. ```python # Before res = await r.json() # After res = await r.json(content_type=None) ``` Five call sites are affected: `image_generations` (openai, gemini, automatic1111 engines) and `image_edits` (openai, gemini engines). ## Testing Verified against Ollama v0.21.2 (`/v1/images/generations`) with model `x/flux2-klein:latest`: - Without fix: `ContentTypeError` raised immediately after generation completes - With fix: response parsed correctly, `b64_json` image returned as expected The change is backwards-compatible — providers returning `application/json` are unaffected. ## Related Issues - #20848 — Ollama image generation connection request - #4915 — Ollama sends `Content-Type: application/x-ndjson` --- <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-18 16:08:47 -05:00

GiteaMirror closed this issue

2026-05-18 16:08:50 -05:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#115193