For the first PDF, the server doesn't handle range requests, although it announces that it does.

t=3694 [st=145]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=3694 [st=145]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                       --> GET /images/pdf/En%20direct%20de%20BBA/MAG%20BBA%2027BD.pdf HTTP/1.1
                           Host: www.bourgenbresse-agglomeration.fr
                           Connection: keep-alive
                           User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36
                           Accept: */*
                           Referer: http://www.bourgenbresse-agglomeration.fr/images/pdf/En%20direct%20de%20BBA/MAG%20BBA%2027BD.pdf
                           Accept-Encoding: gzip, deflate, sdch
                           Accept-Language: en-US,en;q=0.8,fr;q=0.6
                           Range: bytes=3310129-3375664
t=3694 [st=145]     -HTTP_TRANSACTION_SEND_REQUEST
t=3694 [st=145]     +HTTP_TRANSACTION_READ_HEADERS  [dt=147]
t=3694 [st=145]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=147]
t=3841 [st=292]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                       --> HTTP/1.1 416 Requested Range Not Satisfiable
                           Server: nginx
                           Date: Tue, 24 May 2016 21:14:50 GMT
                           Content-Type: text/html; charset=iso-8859-1
                           Transfer-Encoding: chunked
                           Connection: keep-alive
                           Vary: Accept-Encoding
                           Content-Encoding: gzip

While odd, this is correct according to the standard (rfc7233). In this case, we should definitely retry with a full request to the resource.

The second PDF seems to have a different issue. A priori, the server seems to handle the range requests correctly.

For the second bug, a lot of other pdf of the same website works : http://opendata.cts-strasbourg.fr/fiches-horaires/lignes/Fiches%20horaires%20printemps%202016/TramA_23_04_%20OK.pdf

And for the 2nd bug also, I see this pdf with interesting comportment : http://opendata.cts-strasbourg.fr/fiches-horaires/lignes/Fiches%20horaires%20printemps%202016/Ligne57_67_hiver2015_32p.pdf

He fail after first loading but after refresh he load normally

And it's seems to be (for the first) the same issue than #599765 https://bugs.chromium.org/p/chromium/issues/detail?id=599765

I have reported the bug from the website cts-strasbourg to their webmasters, they respond to me it's ONLY a Google Chrome bug, they tested with old versions : no problems.

I can reproduce the problem with Chrome 50.0.2661.102m or 51, but indeed no problem with Chrome 43.0.2357.65m.

The PDFs load for me with Chrome 56. Not sure what changed.

Closing for now. If this is still a problem, please say so.