Mime Magic em arquivos sem extensão no Apache / 2.2.31 e mod_wsgi 3.4

1

Desculpe antecipadamente pela duração, obrigado pela sua paciência. Eu tenho um antigo servidor de produção que ninguém sabe como foi construído. Ele usa o apache + mod_wsgi para executar um aplicativo python Cherry Py para servir imagens. Estou recriando para documentar e começar a atualização. Estou com um problema em que imagens com nenhuma extensão de arquivo que pode ser PNG ou JPEG estão chegando:

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

o servidor de produção atualmente retorna corretamente:

Content-Type: "image/jpeg"

Informações sobre o ambiente em que estou recriando o servidor:

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

O ambiente de produção tem os mesmos pacotes instalados, exceto o fato de estar rodando no Centos6 e o Apache na versão 2.2.17.

Arquivos e snippets relevantes:

link

#/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.

mágica

# /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>

O arquivo que a cherry py usa para exibir a foto:

# /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.

O URL usado para solicitar é algo como:

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

Notas adicionais:

  • O servidor de produção + meu recreio tem cópias exatas do código do cliente, portanto, é muito improvável que o problema esteja no código cherry py / python.
  • Os arquivos host httpd.conf, magic, mime.types, são cópias exatas do que está no servidor de produção, e provavelmente não será o problema.
  • O texto exibido no navegador ao ir para o URL contém JFIF no início, o que significa que ele encontra a imagem.

O que eu fiz até agora:

  • Defina um cabeçalho de resposta personalizado logo após o cabeçalho de resposta Content-Type ser declarado para confirmar se o aplicativo está definindo o valor correto.
  • Locais / permissões de arquivos com verificação tripla, depois outros dois colegas também verificaram.
  • Adicionada uma linha na parte inferior do /etc/httpd/conf/httpd.conf para forçar o cabeçalho Content-Type: Header set Content-Type "image/jpeg" e, em seguida, progressivamente, movê-lo para o topo do arquivo para ver se algum dia será sobrescrito como o cabeçalho do aplicativo, mas enquanto essa linha estiver em qualquer lugar no arquivo conf, ela funcionará / não será sobrescrita. (lembre-se que poderia ser PNG ou JPEG, então, estaticamente, não funcionaria).
  • Produção digitalizada + recreação para encontrar qualquer arquivo .htaccess que possa estar impactando, não há nenhum que eu possa encontrar, executando: sudo find / -type f -name .htaccess não encontra nada.
  • confirmou que todos os módulos apache de produção estão instalados em recreação
  • não confirmou nenhuma mensagem no log de erros, o log de acesso mostra as solicitações conforme o esperado, nada no log do sistema.

Pelo que li em perguntas semelhantes como:

Um dos comentários diz que para o mime_magic funcionar, o mod_mime não deve encontrar nenhuma correspondência, mas como não há extensão, ele encontra um monte de combinações e assim o mime_magic nunca entra no jogo. Isso é exato? Se assim for, posso forçá-lo a sempre usar magia e nunca extensões? Senão, que outros métodos para configurar corretamente o Content-Type para arquivos sem extensão com base no conteúdo?

Outra pessoa dirá que você pode usar uma diretiva ForceType para corresponder a um padrão de arquivo em um diretório específico. Problema é nomes de arquivo são apenas números, não separados por tipo, assim / coisa / 12345 e / coisa / 12346 um pode ser PNG e o outro JPEG, então eu não posso forçar um padrão, eu preciso determinar o tipo baseado em arquivo conteúdo.

Outro foi declarar um tipo de conteúdo errado no aplicativo, mas eu confirmei que esse não é o caso.

Li dezenas de outras respostas e tentei várias soluções, mas acho que estou perdendo algo simples.

Se você chegou até aqui, obrigado pelo seu tempo! Aprecie todas as sugestões. Adicionará informações de depuração ausentes / úteis a pedido!

    
por Chris Robak 20.04.2017 / 02:57

1 resposta

0

A resposta para o meu problema específico foi alguém ter editado manualmente um arquivo de configuração gerado na máquina de produção. Como as configurações geradas não estão comprometidas com o controle de versão e, em vez disso, os modelos para ambientes são copiados para serem a configuração usada com base no ambiente, o modelo também não foi atualizado. Basicamente, se tivéssemos executado um build na máquina de produção, também teria esse problema. A opção de configuração do Cherry Py que eu estava perdendo era:

tools.encode.add_charset = False

Sem isso, o py py substituiu o cabeçalho Content-Type definido no aplicativo. Não tem nada a ver com Apache / mod_mime / magic / modwsgi. Foi tudo uma questão de configuração Cherry Py.

    
por 20.04.2017 / 21:19