Mime Magic для файлов без расширения на Apache/2.2.31 и mod_wsgi 3.4

Извините заранее за длину, спасибо за ваше терпение. У меня есть древний производственный сервер, который никто не знает, как он был построен. Он использует apache+mod_wsgi для запуска Python-приложения Cherry Py для обслуживания изображений. Я воссоздаю его, чтобы задокументировать и начать обновление. Я сталкиваюсь с проблемой, когда изображения без расширения файла, которые могут быть или PNG или JPEG, проходят через:

Content-Type: "text/html;charset=utf-8"

производственный сервер в настоящее время правильно возвращает:

Content-Type: "image/jpeg"

Информация о среде, в которой я воссоздаю сервер:

Amazon Linux AMI release 2017.03 (basically CentOS 6 it feels like)
Apache/2.2.31
mod_wsgi-3.4
CherryPy 3.2.0

В производственной среде установлены те же пакеты, за исключением того, что она работает на реальном Centos6, а Apache версии 2.2.17.

Файлы и соответствующие фрагменты:

httpd.conf

#/etc/httpd/conf/httpd.conf

LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule mime_module modules/mod_mime.so

TypesConfig /etc/mime.types

<IfModule mod_mime_magic.c>
#   MIMEMagicFile /usr/share/magic.mime                                           
   MIMEMagicFile conf/magic
</IfModule>

Include conf.sites/*.conf

# There really are no other directives or AddType calls that are relevant 
# that I can see, just standard  language and icon declarations
# if I should be more verbose here just let me know.

магия

# /etc/httpd/conf/magic
# JPEG images
0       beshort         0xffd8          image/jpeg

mime.types

# /etc/mime.types
image/jpeg                                      jpeg jpg jpe jfif

site.conf

# /etc/httpd/conf.sites/site.conf
<VirtualHost *:80>
    ServerName pic.project.com
    DocumentRoot "/srv/pic_project/html"
    RewriteEngine On                                            
    RewriteCond %{HTTP_USER_AGENT} Apache\sHttpClient [NC]
    RewriteRule . - [F,L]

    <Directory /srv/pic_project/html>
            Order allow,deny
            Allow from all
    </Directory>

    WSGIScriptAlias / /srv/pic_project/src/project.py

    <Directory /srv/pic_project/src>
            Order allow,deny
            Allow from all
    </Directory>

    ErrorLog logs/pic-error_log
    CustomLog logs/pic-access_log combined
</VirtualHost>

Файл, который вишневый пи использует для обслуживания фотографии:

# /srv/pic_project/src/project.py

cherrypy.response.headers['Content-Type'] = cfile.mimetype
cherrypy.response.headers['Cherry-Py-Content-Type'] = cfile.mimetype
cherrypy.response.headers['Content-Disposition'] = 'inline; filename="12345.jpg"'

# I set two headers for debugging. Cherry-Py-Content-Type is always right
# "image/jpeg" or "image/png". "Content-Type" is always "text/html" once
# going through apache / mod_wsgi. Don't worry about "cfile", just know
# the mimetype attribute is always correct.

URL, используемый для запроса, выглядит примерно так:

http://pic.project.com/pics/pic_type/owner_id/12345/

Дополнительные примечания:

• На производственном сервере + моем ресурсе есть точные копии клиентского кода, поэтому вряд ли проблема в коде cherry py / python.
• Файлы httpd.conf, magic, mime.types, файлы виртуальных хостов являются точными копиями того, что находится на рабочем сервере, и опять-таки вряд ли это проблема.
• Текст, отображаемый в браузере при переходе по URL-адресу, содержит JFIF в начале, что означает, что он действительно находит изображение.

Что я сделал до сих пор:

• Установите заголовок пользовательского ответа сразу после объявления заголовка ответа Content-Type, чтобы подтвердить, что приложение устанавливает правильное значение.
• Тройная проверка местоположений / разрешений файлов, затем еще два коллеги также проверили.
• Добавлена ​​строка внизу /etc/httpd/conf/httpd.conf для принудительного использования заголовка Content-Type: Header set Content-Type "image/jpeg", а затем постепенно перемещал его в верхнюю часть файла, чтобы увидеть, будет ли он в конечном итоге перезаписан, как заголовок приложения, но до тех пор, пока эта строка находится где-нибудь в файле conf, она будет работать / не перезаписываться. (помните, что это может быть PNG или JPEG, поэтому статическая настройка не будет работать).
• Сканирование производства + воссоздание, чтобы найти любые файлы.htaccess, которые могут повлиять, я не могу найти, работающие: sudo find / -type f -name .htaccess ничего не находит.
• подтвердили, что все производственные модули apache установлены на базе отдыха
• в журнале ошибок нет подтвержденных сообщений, в журнале доступа отображаются ожидаемые запросы, в системном журнале ничего нет.

Из того, что я прочитал в подобных вопросах, как:

• Заставить Apache распознавать MIME-тип файлов без расширения
• Неверный тип MIME - выдергивание волос
• Apache возвращает текст / HTML на некоторых файлах PNG

В одном из комментариев говорится, что для того, чтобы mime_magic работал, mod_mime не должен находить совпадений, но, поскольку нет расширения, он находит кучу совпадений, и поэтому mime_magic даже не входит в игру. Это точно? Если да, могу ли я заставить его всегда использовать магию, а не расширения? Иначе, какие еще методы для правильной настройки Content-Type для файлов без расширения на основе контента?

Другой скажет, что вы можете использовать ForceType директива, чтобы соответствовать файлу-образцу в определенном каталоге. Проблема в том, что имена файлов - это просто числа, не разделенные по типу, поэтому /thing/12345 и /thing/12346, один из них может быть PNG, а другой JPEG, поэтому я не могу форсировать шаблон, мне нужно определить тип на основе файла. содержание.

Еще один провозглашал неправильный тип контента в приложении, но я подтвердил, что это не так.

Я прочитал десятки других ответов и пробовал несколько обходных путей, но я думаю, что мне просто не хватает чего-то простого..

Если вы получили это далеко, спасибо за ваше время! Ценю любые предложения. Добавит недостающие / полезные данные отладки по запросу!