Texto em vez de imagens

1

Vá para a página seguinte, Yahoo Answers Há uma captura de tela do problema pela pergunta proprietário. Quando clico na imagem para vê-la, , uma janela com tantos caracteres e que não faz o menor sentido. Estou usando a última atualização do firefox. Mas esse problema não existe no Torch

    
por RogUE 24.12.2014 / 15:57

1 resposta

5

Os cabeçalhos de resposta incluem:

Content-Type: text/plain; charset=utf-8

Esta é uma mensagem do servidor para o navegador informando que os dados que estão enviando são de um certo tipo ( text/plain com codificação UTF-8 neste caso), e o navegador deve interpretar os dados como tal. A forma como os dados são eventualmente exibidos depende do navegador, mas o navegador deve assumir que Content-Type está correto em vez de olhar para a extensão (que pode nem existir em uma URL) ou tentar analisar os dados. Em outras palavras, ele deve tratar todos text/plain da mesma maneira.

O Firefox está apenas fazendo o que o servidor lhe diz para fazer. O servidor está com uma resposta incorreta (atualmente estamos supondo que isso realmente deveria ser uma imagem - correto neste caso, mas não em todos os casos), portanto, por que os navegadores não podem detectar isso com segurança. / p>

Se você realmente quiser, salve a imagem e abra-a em um visualizador de imagens. Você também pode instalar um um addon para forçar qualquer URL que termine em .jpeg para ser renderizado como uma imagem - mas observe que isso pode prejudicar outras coisas.

No final do dia, o servidor está fazendo a coisa errada - e, no que diz respeito aos padrões da web, a FF está fazendo a coisa certa ao ouvi-lo.

Observe que a RFC 2616 diz:

Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".

O mais recente substituto RFC 2731 observa que alguns navegadores adivinham mesmo assim, mas isso não é recomendado:

In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation, with the result that some clients will examine a payload's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.

A questão é que qualquer fluxo de dados arbitrário pode parecer um JPEG por extensão ou por conteúdo, mas se a fonte não pretender ser uma imagem, então interpretá-lo como tal seria errado. Quando um Content-Type é fornecido, os navegadores devem confiar no servidor para saber o que está fazendo e interpretar os dados conforme o cabeçalho especifica.

    
por 24.12.2014 / 16:11