baixar PDF pendurado no servidor com o Firefox / Chrome

Question

Eu tenho um servidor Windows 2008 R2 (virtual) executando vários sites. Meu cliente enviou vários PDFs por FTP para um diretório de download de onde eles podem ser recuperados por meio de uma página da Web.

Isso funciona bem no IE e no Safari, mas ao tentar fazer o download com o Firefox ou o Chrome, os dois navegadores ficam suspensos e as postagens do Firefox 'pararam' na barra de status na parte inferior da página. Nós tentamos isso em vários PCs em diferentes locais, então acho que isso pode ser um problema no servidor - embora concebivelmente o software usado para gerar os PDFs possa ter produzido algo incompatível com o streaming para o Firefox / Chrome.

Por que razões podem existir para produzir esse comportamento? Existe alguma configuração que eu precise mudar?

EDIT: cabeçalhos verificados com o Firebug - um GET adere com um conteúdo parcial 206

Content-Type    application/pdf
Last-Modified   Sun, 21 Mar 2010 19:50:49 GMT
Accept-Ranges   bytes
Etag    "42da4bce2fc9ca1:0"
Server  Microsoft-IIS/7.5
X-Powered-By    ASP.NET
Date    Thu, 27 May 2010 15:39:34 GMT
Content-Length  329532
Content-Range   bytes 27484-357015/357016
Request Headersview source
Host    www.caepost.co.uk
User-Agent  Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  115
Connection  keep-alive
Range   bytes=27484-357015,27484-27485

    

Answer 1

O IIS versão 7.5 mudou a maneira como responde a solicitações de intervalo de bytes, como aquelas feitas pelo plug-in do Acrobat. Se a solicitação for para um único intervalo contíguo, o IIS agora responde com o cabeçalho "Content-Range" em vez do cabeçalho "ContentType: multipart / byteranges", que na verdade é um HTTP válido, mas confunde o plug-in do Acrobat.

A Adobe está atualmente trabalhando em uma correção: link

E, enquanto isso, a Microsoft forneceu um hotfix para fazer o IIS 7.5 voltar ao antigo comportamento: link

    

Answer 2

Atualizamos os servidores e o IIS 7.5 nos deu esse mesmo problema. Verificou os cabeçalhos e confirmou o problema.

Aplicamos o link no hotfix, mas isso não resolveu o problema. Acho que a diferença aqui é que nosso site estava rodando no modo clássico. (Teve que fazer isso por outro produto (Imis) instalado). Portanto, parece que o hotfix só funciona se o site estiver sendo executado no modo integrado.

No final, tive que escrever um manipulador para pegar as solicitações de documentos em PDF e alterar o cabeçalho da resposta.

context.Response.ContentType = "application/pdf";
context.Response.TransmitFile(filePath);
context.Response.End();

Isso funcionou.

Os sintomas não se limitaram ao Acrobat abrindo os documentos. No nosso caso, o google chrome também estava pendurado quando tentou abrir o pdf, independentemente do seu leitor de pdf.

    

Answer 3

Você pode postar os cabeçalhos de resposta enviados?

Painel do Firebug Net:

Visualizaçãodecabeçalhos:

    

Answer 4

Isso pode ser devido a configurações de compactação no IIS 7.0.

O cabeçalho da solicitação contém o seguinte:

Accept-Encoding: gzip,deflate

para indicar que o navegador aceita conteúdo compactado.

Quando você usa:

context.Response.TransmitFile(filePath);

O IIS analisa o tipo de conteúdo que está definido e decide se deseja compactar a resposta.

Infelizmente, o IIS não parece adicionar

Content-Encoding: gzip

para o cabeçalho Response, o que significa que o Firefox e o Chrome não podem determinar se os dados estão compactados ou não.

Desativar a compactação de conteúdo no IIS deve corrigir isso, mas afetará todo o site. Além disso, a sugestão de definir um tipo de conteúdo pode funcionar em algumas circunstâncias. O IIS 7 decide se deve compactar a resposta com base no tipo MIME.

link fornece o seguinte exemplo para configurar o httpCompression em seu arquivo ApplicationHost.config:

<httpCompression
      directory="%SystemDrive%\inetpub\temp\IIS Temporary Compressed Files">
   <scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
   <dynamicTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/javascript" enabled="true" />
      <add mimeType="*/*" enabled="false" />
   </dynamicTypes>
   <staticTypes>
      <add mimeType="text/*" enabled="true" />
      <add mimeType="message/*" enabled="true" />
      <add mimeType="application/javascript" enabled="true" />
      <add mimeType="*/*" enabled="false" />
   </staticTypes>
</httpCompression>

Outra opção é garantir que 'Content-Encoding: gzip' seja sempre adicionado ao cabeçalho Response, mas você precisará ter cuidado para garantir que a resposta seja realmente compactada, o que pode não ser para todos os tipos de conteúdo .