Pdf.js: Refus d'obtenir un en-tête non sécurisé "Accept-Ranges" avec des URL Amazon

Voyez-vous cela avec viewer.html ou l'extension firefox ?

avec spectateur.html

Je pense que cela échoue parce que vous faites une demande d'origine croisée.

Si vous avez Chrome, voyez si cela fonctionne :

Exécutez Chrome avec --disable-web-security (http://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy). Lors du chargement du fichier, ajoutez également #disableWorker=true .

Fermeture. Veuillez rouvrir si le problème persiste.

Merci @mduan pour votre réponse,
mais la même erreur m'apparaît toujours, et pour mieux l'expliquer, j'ai mis la visionneuse en dropbox et voici les liens publics que vous pouvez essayer :
https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer.html
cette visionneuse donne l'erreur :

mais quand j'ai changé le chemin pdf de
DEFAULT_URL=' https://kotob.s3.amazonaws.com/neo.pdf '
à :
DEFAULT_URL='neo.pdf'
en plaçant le fichier dans le même répertoire de visionneuse, cela fonctionne bien avec les requêtes de plage :

https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer2.html
et notez que nous rendons la politique CORS accessible à partir de toute autre origine pour les requêtes get.
J'espère que cela peut aider à expliquer le problème.
et désolé pour ma réponse tardive,

de l'aide ?

J'ai pu reproduire le problème sur un serveur local. Je l'ai fait fonctionner en demandant au serveur hébergeant le PDF distant de renvoyer les en-têtes HTTP suivants :

Access-Control-Allow-Headers: Range
Access-Control-Expose-Headers: Accept-Ranges, Content-Encoding, Content-Length, Content-Range

merci @mduan pour votre aide, cela fonctionne maintenant.

@mahmoudfelfel : pourriez-vous fermer ce sujet si votre problème est résolu ? Merci! :)

Proxy File dans un langage de script ( PHP, RoR, Python ou autre ) est une solution très simple.

Je suis tombé sur la même erreur. Et à mon avis, cela peut/doit être corrigé dans pdf.js.

Lors du chargement d'un pdf à partir d'un autre domaine, puis le nôtre. Une demande de contrôle en amont est obligatoire, non seulement pour AWS, mais en ce qui concerne les documents Mozilla , elle est recommandée pour chaque demande CORS.

Ensuite, vous pouvez éviter une instance de proxy supplémentaire ou autre. Comme un travail rapide, je vais essayer de récupérer la demande pdf (avec un contrôle en amont) pour moi-même et de simplement passer le ByteArray dans pdf.js.

Lors du chargement d'un pdf à partir d'un autre domaine, puis le nôtre. Une demande de contrôle en amont est obligatoire, non seulement pour AWS, mais en ce qui concerne les documents Mozilla, elle est recommandée pour chaque demande CORS.

Les demandes de contrôle en amont CORS sont générées automatiquement par XHR sans intervention des utilisateurs JS.

Comme un travail rapide, je vais essayer de récupérer la demande pdf (avec un contrôle en amont) pour moi-même et de simplement passer le ByteArray dans pdf.js.

Cela semble être une solution de contournement parfaite : tous les moyens de communication non standard (à l'exception de l'accès HTTP/HTTPS simple sans besoin de CORS) doivent être gérés par l'utilisateur. Si vous êtes sûr que XHR pourra avoir votre URL (fichier, blob, avec CORS, avec en-tête d'authentification, etc.), configurez-le correctement.

Fermer comme ne résoudra pas.

Je suis coincé avec v0.8.180 et je sais que c'est un vieux problème, même si cela aide quelqu'un d'autre, la configuration CORS du compartiment S3 suivante l'a résolu pour moi :

<?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 J'ai essayé la même configuration dans notre configuration CORS de compartiment S3. L'application fonctionne dans tous les navigateurs et FireFox n'a aucune erreur. Webkit (Chrome/Safari) lance toujours Refused to get unsafe header "Accept-Ranges" .

J'ai remarqué que Accept-Ranges: bytes est présent sur la requête http du fichier pdf, mais je ne vois pas Content-Range ou Content-Encoding persister de la configuration à la requête http.

Peut-être qu'il doit exposer Range en plus de Content-Range ?

Je lui ai donné un coup sans chance. Décidé de botter en touche sur la question.

Une configuration CORS fonctionnelle peut être trouvée ici : https://github.com/mozilla/pdf.js/issues/4530#issuecomment -188059771

La clé pour que cela fonctionne est la "gamme" Access-Control-Allow-Headers.

Dans mon cas, mais pour le streaming de contenu audio, ces en-têtes ne fonctionnaient pas de toute façon

@simoncpu merci pour vos trouvailles !
J'ai un problème très similaire, mais pour le contenu audio. Dans mon cas, ces en-têtes ne fonctionneront pas d'ailleurs

{ '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' }

demandé sur SF ainsi.