Pdf.js: Recusou-se a obter o cabeçalho inseguro "Accept-Ranges" com URLs da Amazon

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.