Estou tentando usar o pdf.js com requisições de intervalo (carregamento progressivo do documento pdf), mas quando tento carregar os pdfs das urls do amazon s3 aparece este erro no console:
Recusou-se a obter o cabeçalho inseguro "Accept-Ranges"
e o pdf não carrega por meio de 206 conteúdo parcial (solicitações de intervalo), mas 200 e após o download do pdf concluído, é visualizado no visualizador.
este é um exemplo de URL de pdf:
https://kotob.s3.amazonaws.com/book.pdf?Signature=irgVfoAZuPPIp5kpCesni2MzpLo%3D&Expires=1366576877&AWSAccessKeyId=AKIAILBHXSTPUIBTRMSA
qualquer ajuda
Você está vendo isso com viewer.html ou a extensão do firefox?
com visualizador.html
Acho que isso está falhando porque você está fazendo uma solicitação de origem cruzada.
Se você tem o Chrome, veja se funciona:
Execute o Chrome com --disable-web-security
(http://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy). Ao carregar o arquivo, acrescente também #disableWorker=true
.
Fechamento. Por favor, reabra se ainda for um problema.
Obrigado @mduan pela sua resposta,
mas o mesmo erro ainda aparece para mim, e para explicar melhor, eu coloco o visualizador na caixa de depósito e estes são os links públicos que você pode tentar:
https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer.html
este visualizador dá o erro:
mas quando eu mudei o caminho do pdf de
DEFAULT_URL=' https://kotob.s3.amazonaws.com/neo.pdf '
para :
DEFAULT_URL='neo.pdf'
colocando o arquivo no mesmo diretório do visualizador, ele funciona bem com solicitações de intervalo:
https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer2.html
e observe que estamos tornando a política CORS acessível de qualquer outra origem para solicitações de obtenção.
espero que possa ajudar a explicar o problema.
e desculpe a demora em responder,
qualquer ajuda ?
Consegui reproduzir o problema em um servidor local. Consegui que funcionasse fazendo com que o servidor que hospeda o PDF remoto retornasse os seguintes cabeçalhos HTTP:
Access-Control-Allow-Headers: Range
Access-Control-Expose-Headers: Accept-Ranges, Content-Encoding, Content-Length, Content-Range
obrigado @mduan por sua ajuda, está funcionando agora.
@mahmoudfelfel : você poderia fechar este problema se o seu problema for corrigido? Obrigada! :)
Arquivo Proxy em uma linguagem de script, ( PHP, RoR, Python ou outra ) é uma solução muito fácil.
Eu tropecei no mesmo erro. E na minha opinião isso pode/deve ser corrigido dentro do pdf.js.
Ao carregar um pdf de outro domínio, então o nosso. Uma solicitação de comprovação é obrigatória, não apenas para AWS, mas em relação aos documentos da Mozilla , é recomendado para todas as solicitações CORS.
Então você pode evitar uma instância de proxy extra ou algo assim. Como uma solução rápida, tentarei buscar a solicitação de pdf (com um preflight) para mim e apenas passar o ByteArray para pdf.js.
Ao carregar um pdf de outro domínio, então o nosso. Uma solicitação de comprovação é obrigatória, não apenas para AWS, mas em relação aos documentos da Mozilla, é recomendado para todas as solicitações CORS.
As solicitações de comprovação do CORS são geradas pelo XHR automaticamente sem a intervenção do JS dos usuários.
Como uma solução rápida, tentarei buscar a solicitação de pdf (com um preflight) para mim e apenas passar o ByteArray para pdf.js.
Parece uma solução perfeita: todos os meios de comunicação não padrão (exceto HTTP/HTTPS simples sem necessidade de CORS) devem ser tratados pelo usuário. Se você tiver certeza de que o XHR poderá ter seu url (arquivo, blob, com CORS, com cabeçalho de autenticação, etc) configure-o corretamente.
Fechar como não vai corrigir.
Estou preso com v0.8.180
e sei que esse é um problema antigo, embora, caso ajude mais alguém, a seguinte configuração CORS do bucket S3 o corrigiu para mim:
<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedHeader>*</AllowedHeader>
<ExposeHeader>Accept-Ranges</ExposeHeader>
<ExposeHeader>Content-Range</ExposeHeader>
<ExposeHeader>Content-Encoding</ExposeHeader>
<ExposeHeader>Content-Length</ExposeHeader>
</CORSRule>
</CORSConfiguration>
@jpillora Eu tentei a mesma configuração em nossa configuração CORS do bucket S3. O aplicativo funciona em todos os navegadores e o FireFox não apresenta erros. Webkit (Chrome/Safari) ainda joga Refused to get unsafe header "Accept-Ranges"
.
Percebi que Accept-Ranges: bytes
está presente na solicitação http do arquivo pdf, mas não estou vendo Content-Range
ou Content-Encoding
persistirem da configuração na solicitação http.
Talvez precise expor Range além de Content-Range?
Eu dei uma chance sem sorte. Resolveu apostar no assunto.
Uma configuração CORS funcional pode ser encontrada aqui: https://github.com/mozilla/pdf.js/issues/4530#issuecomment -188059771
A chave para fazer isso funcionar é o "intervalo" de acesso-controle-permitir-cabeçalhos.
No meu caso, mas para streaming de conteúdo de áudio, esses cabeçalhos não estavam funcionando de qualquer maneira
@simoncpu obrigado por suas descobertas!
Eu tenho um problema muito semelhante, mas para conteúdo de áudio. No meu caso, esses cabeçalhos não funcionarão a propósito
{ 'Content-Length': 5751405,
'Content-Type': 'audio/mpeg',
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Methods': 'POST, GET, OPTIONS',
'Access-Control-Allow-Headers': 'Range',
Expires: 0,
Pragma: 'no-cache',
'Cache-Control': 'no-cache, no-store, must-revalidate',
'Accept-Ranges': 'bytes',
'Content-Range': 'bytes 120429-240237/5751405' }
perguntou em SF também.
Comentários muito úteis
Consegui reproduzir o problema em um servidor local. Consegui que funcionasse fazendo com que o servidor que hospeda o PDF remoto retornasse os seguintes cabeçalhos HTTP: