Pdf.js: Se negó a obtener el encabezado inseguro "Accept-Ranges" con URL de Amazon

¿Estás viendo esto con viewer.html o la extensión de Firefox?

con visor.html

Siento que esto está fallando porque está haciendo una solicitud de origen cruzado.

Si tienes Chrome, mira si esto funciona:

Ejecute Chrome con --disable-web-security (http://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy). Al cargar el archivo, agregue también #disableWorker=true .

Clausura. Vuelva a abrir si sigue siendo un problema.

Gracias @mduan por tu respuesta,
pero me sigue apareciendo el mismo error, y para explicarlo mejor, puse el visor en dropbox y estos son los enlaces publicos puedes probarlo:
https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer.html
este visor da el error:

pero cuando cambié la ruta del pdf de
DEFAULT_URL=' https://kotob.s3.amazonaws.com/neo.pdf '
a :
DEFAULT_URL='neo.pdf'
al colocar el archivo en el mismo directorio del visor, funciona bien con solicitudes de rango:

https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer2.html
y tenga en cuenta que estamos haciendo que la política de CORS sea accesible desde cualquier otro origen para obtener solicitudes.
Espero que pueda ayudar a explicar el problema.
y lo siento por mi respuesta tardía,

alguna ayuda ?

Pude reproducir el problema en un servidor local. Conseguí que funcionara haciendo que el servidor que aloja el PDF remoto devolviera los siguientes encabezados HTTP:

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

gracias @mduan por tu ayuda, ahora está funcionando.

@mahmoudfelfel : ¿podría cerrar este problema si se soluciona su problema? ¡Gracias! :)

El archivo proxy en un lenguaje de secuencias de comandos (PHP, RoR, Python u otro) es una solución muy fácil.

Me encontré con el mismo error. Y en mi opinión, esto puede/debería arreglarse dentro de pdf.js.

Al cargar un pdf de otro dominio, entonces el nuestro. Las solicitudes de verificación previa son obligatorias, no solo para AWS, sino que, con respecto a los documentos de Mozilla , se recomiendan para cada solicitud de CORS.

Entonces puede evitar una instancia de proxy adicional o algo así. Como una solución rápida, intentaré obtener la solicitud de pdf (con una verificación previa) por mi cuenta y simplemente pasar el ByteArray a pdf.js.

Al cargar un pdf de otro dominio, entonces el nuestro. Las solicitudes de verificación previa son obligatorias, no solo para AWS, sino que, con respecto a los documentos de Mozilla, se recomiendan para cada solicitud de CORS.

Las solicitudes de verificación previa de CORS son generadas por XHR automáticamente sin la intervención de JS de los usuarios.

Como una solución rápida, intentaré obtener la solicitud de pdf (con una verificación previa) por mi cuenta y simplemente pasar el ByteArray a pdf.js.

Suena como una solución perfecta: todos los medios de comunicación no estándar (excepto HTTP/HTTPS sin necesidad de CORS) deben ser manejados por el usuario. Si está seguro de que XHR podrá tener su URL (archivo, blob, con CORS, con encabezado de autenticación, etc.), configúrelo correctamente.

Cerrando como no arreglará.

Estoy atascado con v0.8.180 y sé que este es un problema antiguo, aunque en caso de que ayude a alguien más, la siguiente configuración CORS del depósito S3 lo arregló para mí:

<?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 Probé la misma configuración en nuestra configuración CORS del depósito S3. La aplicación funciona en todos los navegadores y FireFox no tiene errores. Webkit (Chrome/Safari) aún lanza Refused to get unsafe header "Accept-Ranges" .

Noté que Accept-Ranges: bytes está presente en la solicitud http del archivo pdf, pero no veo que Content-Range o Content-Encoding persistan desde la configuración en la solicitud http.

¿Tal vez necesita exponer Range además de Content-Range?

Le di una oportunidad sin suerte. Decidió dejar de lado el tema.

Puede encontrar una configuración de CORS en funcionamiento aquí: https://github.com/mozilla/pdf.js/issues/4530#issuecomment -188059771

La clave para hacer que esto funcione es el "rango" de Access-Control-Allow-Headers.

En mi caso, pero para la transmisión de contenido de audio, estos encabezados no funcionaban de todos modos

@simoncpu ¡ gracias por tus hallazgos!
Tengo un problema muy similar, pero para contenidos de audio. En mi caso, estos encabezados no funcionarán por cierto.

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

preguntó en SF también.