Pdf.js: Weigerte sich, unsichere Header "Accept-Ranges" mit Amazon-URLs zu erhalten

Sehen Sie dies mit viewer.html oder der Firefox-Erweiterung?

mit viewer.html

Ich habe das Gefühl, dass dies fehlschlägt, weil Sie eine Cross-Origin-Anfrage stellen.

Wenn Sie Chrome haben, prüfen Sie, ob dies funktioniert:

Führen Sie Chrome mit --disable-web-security (http://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy) aus. Hängen Sie beim Laden der Datei auch #disableWorker=true an.

Schließen. Bitte erneut öffnen, falls das Problem weiterhin besteht.

Danke @mduan für deine Antwort,
aber der gleiche Fehler erscheint mir immer noch, und um es besser zu erklären, habe ich den Viewer in Dropbox eingefügt und dies sind die öffentlichen Links, die Sie ausprobieren können:
https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer.html
dieser Viewer gibt den Fehler:

aber wenn ich den pdf-pfad von geändert habe
DEFAULT_URL=' https://kotob.s3.amazonaws.com/neo.pdf '
zu :
DEFAULT_URL='neo.pdf'
Indem Sie die Datei in dasselbe Viewer-Verzeichnis legen, funktioniert es gut mit Bereichsanforderungen:

https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer2.html
und beachten Sie, dass wir die CORS-Richtlinie für Get-Anforderungen von jedem anderen Ursprung aus zugänglich machen.
Ich hoffe, das kann zur Erklärung des Problems beitragen.
und entschuldige meine späte Antwort,

irgendeine Hilfe ?

Ich konnte das Problem auf einem lokalen Server reproduzieren. Ich habe es zum Laufen gebracht, indem ich den Server, auf dem das Remote-PDF gehostet wird, die folgenden HTTP-Header zurückgeben lässt:

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

Danke @mduan für deine Hilfe, es funktioniert jetzt.

@mahmoudfelfel : Könnten Sie dieses Thema schließen, wenn Ihr Problem behoben ist? Danke schön! :)

Proxy-Datei in einer Skriptsprache (PHP, RoR, Python oder eine andere) ist eine sehr einfache Lösung.

Ich bin über den gleichen Fehler gestolpert. Und meiner Meinung nach kann / sollte dies in pdf.js behoben werden.

Beim Laden eines PDFs von einer anderen Domain, dann unserer eigenen. Eine Preflight-Anfrage ist obligatorisch, nicht nur für AWS, sondern in Bezug auf Mozilla -Dokumente wird sie für jede CORS-Anfrage empfohlen.

Dann können Sie eine zusätzliche Proxy-Instanz oder ähnliches vermeiden. Als schnelle Lösung werde ich versuchen, die PDF-Anfrage (mit einem Preflight) für mich selbst abzurufen und das ByteArray einfach an pdf.js zu übergeben.

Beim Laden eines PDFs von einer anderen Domain, dann unserer eigenen. Eine Preflight-Anfrage ist obligatorisch, nicht nur für AWS, sondern in Bezug auf Mozilla-Dokumente wird sie für jede CORS-Anfrage empfohlen.

CORS-Preflight-Anfragen werden von XHR automatisch ohne Eingreifen des JS des Benutzers generiert.

Als schnelle Lösung werde ich versuchen, die PDF-Anfrage (mit einem Preflight) für mich selbst abzurufen und das ByteArray einfach an pdf.js zu übergeben.

Klingt nach perfekter Problemumgehung: Alle nicht standardmäßigen Kommunikationsmittel (mit Ausnahme von reinem HTTP/HTTPS ohne CORS-Bedarf) müssen vom Benutzer gehandhabt werden. Wenn Sie sicher sind, dass XHR Ihre URL (Datei, Blob, mit CORS, mit Auth-Header usw.) verwenden kann, konfigurieren Sie dies richtig.

Schließen als wird nicht behoben.

Ich stecke mit v0.8.180 fest und ich weiß, dass dies ein altes Problem ist, aber falls es jemand anderem hilft, hat die folgende S3-Bucket-CORS-Konfiguration es für mich behoben:

<?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 Ich habe dieselbe Konfiguration in unserer CORS-Konfiguration für S3- Refused to get unsafe header "Accept-Ranges" .

Ich habe bemerkt, dass Accept-Ranges: bytes in der HTTP-Anfrage der PDF-Datei vorhanden ist, aber ich sehe nicht, dass Content-Range oder Content-Encoding von der Konfiguration in der HTTP-Anfrage bestehen bleiben.

Vielleicht muss es Range zusätzlich zu Content-Range verfügbar machen?

Ich habe es ohne Glück versucht. Beschlossen, auf das Problem einzugehen.

Eine funktionierende CORS-Konfiguration finden Sie hier: https://github.com/mozilla/pdf.js/issues/4530#issuecomment -188059771

Der Schlüssel dafür, dass dies funktioniert, ist Access-Control-Allow-Headers "range".

In meinem Fall, aber zum Streamen von Audioinhalten, funktionierten diese Header sowieso nicht

@simoncpu danke für deine Erkenntnisse!
Ich habe ein sehr ähnliches Problem, aber für Audioinhalte. In meinem Fall funktionieren diese Header übrigens nicht

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

fragte auch auf SF .