Pdf.js: Refused to get unsafe header "Accept-Ranges" with amazon urls

Are you seeing this with viewer.html or the firefox extension?

with viewer.html

I feel this is failing because you are making a cross-origin request.

If you have Chrome, see if this works:

Run Chrome with --disable-web-security (http://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy). When loading the file, also append #disableWorker=true.

Closing. Please reopen if it's still an issue.

Thanks @mduan for your response ,
but the same error still appears to me ,and to explain it better ,i put the viewer in dropbox and this is the public links you can try it :
https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer.html
this viewer gives the error :

but when i changed the pdf path from
DEFAULT_URL='https://kotob.s3.amazonaws.com/neo.pdf'
to :
DEFAULT_URL='neo.pdf'
by putting the file in the same viewer directory ,it works fine with range requests:

https://dl.dropboxusercontent.com/u/37262502/PDF.js_mduan/pdf.js/web/viewer2.html
and note that we are making the CORS policy accessible from any other origin for get requests.
i hope that can help in explaining the problem .
and i'm sorry for my late response,

any help ?

I was able to repro the issue on a local server. I got it to work by having the server hosting the remote PDF return the following HTTP headers:

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

thanks @mduan for your help , it is working now .

@mahmoudfelfel: could you close this issue if your problem is fixed? Thank you! :)

Proxy File in a scripting language, ( PHP, RoR, Python or another ) is a very easy solution.

I stumbled upon the same error. And in my opinion this can / should be fixed within pdf.js.

When loading a pdf from an other domain, then our own. A preflight requests is mandatory, not only for AWS but regarding to Mozilla docs it's recommended for every CORS request.

Then you can avoid a extra proxy instance or such. As a quick work around I will try to fetch the pdf (with a preflight) request for my own and just pass the ByteArray into pdf.js.

When loading a pdf from an other domain, then our own. A preflight requests is mandatory, not only for AWS but regarding to Mozilla docs it's recommended for every CORS request.

CORS preflight requests are generated by XHR automatically without users JS intervention.

As a quick work around I will try to fetch the pdf (with a preflight) request for my own and just pass the ByteArray into pdf.js.

Sounds as perfect workaround: all non-standard means of communication (except plain HTTP/HTTPS get without CORS need) shall be handled by user. If you are sure that XHR will be able to have your url (file, blob, with CORS, with auth header, etc) configure that properly.

Closing as won't fix.

I'm stuck with v0.8.180 and I know this is an old issue, though incase it helps anyone else, the following S3 bucket CORS config fixed it for me:

<?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 I've tried the same configuration in our S3 bucket CORS config. The application works in all browsers, and FireFox has no errors. Webkit (Chrome/Safari) still throw Refused to get unsafe header "Accept-Ranges".

I did notice that Accept-Ranges: bytes is present on the pdf file http request, but I'm not seeing Content-Range or Content-Encoding persist from the configuration into the http request.

Maybe it needs to expose Range in addition to Content-Range?

I gave it a shot without luck. Decided to punt on the issue.

A working CORS config can be found here: https://github.com/mozilla/pdf.js/issues/4530#issuecomment-188059771

The key to making this work is Access-Control-Allow-Headers "range".

In my case, but for streaming audio contents, these headers were not working anyways

@simoncpu thank you for your findings!
I have a very similar issue, but for audio contents. In my case these headers will not work by the way

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

asked on SF as well.