The response appears to be coming from a Swift-backed object where the original object metadata is preserved through the cache layer. In other words, the Content-Type: application/ogg header is most likely stored as object metadata, rather than being set dynamically by Envoy or another frontend component.

That suggests the issue is occurring earlier in the pipeline:

The incorrect MIME type is likely assigned during upload or metadata handling in MediaWiki

This value is then persisted in Swift as object metadata

The cache/frontend layers simply return it unchanged

This means the correct place to address the issue for future uploads is likely within MediaWiki’s media handling or MIME type assignment logic, rather than in the Swift layer itself.

Change #1254858 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/extensions/TimedMediaHandler@master] OggHandler: Register handler for audio/ogg and video/ogg MIME types

https://gerrit.wikimedia.org/r/1254858

Change #1254862 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/core@master] mime: Use RFC 5334 MIME types for OGG files (audio/ogg, video/ogg)

https://gerrit.wikimedia.org/r/1254862

Change #1254870 had a related patch set uploaded (by Arendpieter; author: Arendpieter):

[mediawiki/extensions/TimedMediaHandler@master] tests: Update expected MIME type for OGG video upload test

https://gerrit.wikimedia.org/r/1254870