I have a webpage (http://optiswissopen2015.ch/page/noticeboard) with some PDFs on it. All of them are linked the same way. But on some browsers (IE8 for sure) they are shown as text instead of open a pdf viewer.
<a href=" /files/Noticeboard/1436883318_sism2015.pdf"
download runat="server" class="button color3">
My first thought was, that they may have a problem in the header. But converting them to .ps and back doesn't help.
What can I do, that they open right with all browsers?
As a last option, I could ZIP them :-(
Yes, the the issue is in the file content type returned for some PDF files on your server. To verify it use curl -i [url] or wget -S [url] or this online tool.
For example, 1436883318_sism2015.pdf returns (incorrect):
HTTP/1.1 200 OK
ETag: "[omitted]"
Last-Modified: Tue, 14 Jul 2015 14:15:18 GMT
Content-Type: text/plain
Content-Length: 1188394
Date: Mon, 27 Jul 2015 17:19:21 GMT
Accept-Ranges: bytes
Server: LiteSpeed
Connection: close
And anmedleguide.pdf returns the correct header:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2015 17:21:25 GMT
Server: Apache/2.4.10 (Unix)
Last-Modified: Fri, 17 Jul 2015 13:07:01 GMT
ETag: "[omitted]"
Accept-Ranges: bytes
Content-Length: 932698
Content-Type: application/pdf
Why don't you try and integrate pdf.js.
I opened up your page in mozilla and the all the pdf's are being displayed nicely(Mozilla Firefox by default opens up a pdf in pdf.js). So you can integrate it in your website and get to display the pdf's in the same manner irrespective of the browser.
On the link below I have explained how to set-up pdf.js easily. (Just use your actual server instead of localhost mentioned there.)
Look on this link.
It will take only a few minutes to set-it up and the pdf issue will vanish for sure.
Related
I am trying to cache some images and using the DevTools of MS Edge to analyze the network.
The URL should return only the image via readfile($image) and I see the image correctly in the browser.
Response Headers:
HTTP/1.1 200 OK
Date: Mon, 25 May 2020 19:18:56 GMT
Server: Apache/2.4.38
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: max-age=86400
Pragma: no-cache
Debugbar-Time: 1590434336
Debugbar-Link: https://blog.casa.spiti/?debugbar_time=1590434336
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: image/jpeg
The Network Tab of the Chrome Dev Tools shows document for the image.
Questions to this output:
What is this expire date of 1981? How do I change it?
Is this the reason why the image is not cached?
Why is the image being indicated as document? Is it because I use readfile()?
Impossible to answer without seeing your server config.
Shouldn’t be, cache-control is used in preference to Expires.
If you are loading the image directly in the browser it shows as document - even if it’s an image. That image is the document in that case. If you load the image as part of an HTML document, then it will show as Image in Dev Tools.
I have configured apache http with some cache settings. However, it does not seem to work properly and the browser seems to keep fetching the file as if it's not cached.
I tried to debug it by fetching the header.
$ curl -skI https://whatever-url-it-is/some-script.js
HTTP/1.1 200 OK
Date: Sun, 15 Sep 2019 05:35:08 GMT
Server: Apache/2.4.39 (Amazon) OpenSSL/1.0.2k-fips PHP/5.6.40
Last-Modified: Sun, 02 Jul 2017 10:52:25 GMT
ETag: "152ba-5535372162c40"
Accept-Ranges: bytes
Content-Length: 86714
Cache-Control: max-age=2592000, public
Expires: Tue, 17 Sep 2019 05:35:08 GMT
Vary: Accept-Encoding,User-Agent
Content-Type: text/javascript
The Cache-Control header seems to be correct. The Expires header looks a little odd but according to this page (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires) the Expire will be ignored given that Cache-Control is there.
What else can I do to debug this issue? Any idea is very well welcome. Thanks
Never mind. I didn't realized that "Disable Cache" was turned on in Chrome. User error :-)
I am accessing OneDrive from a C++ program using WinHttp* functions. What absolutely baffles me is REST API download command. I am downloading a small test picture with
GET /v1.0/drive/items/FF306293D40F9529!158/content
When I do this in the console, I get a response exactly as described in the docs, that is, a 302 redirect to the actual content. However when I send the same request with WinHttpSendRequest, I receive the actual file contents instead of a redirection:
HTTP/1.1 200 OK
Cache-Control: public
Date: Wed, 06 Jan 2016 10:22:36 GMT
Content-Length: 161796
Content-Type: image/jpeg
Content-Location: https://public-bn1306.files.1drv.com/blahblahbla
Expires: Tue, 05 Apr 2016 10:22:36 GMT
Last-Modified: Wed, 06 Jan 2016 10:22:35 GMT
Accept-Ranges: bytes
ETag: aRkYzMDYyOTNENDBGOTUyOSExNTguMw
P3P: CP="BUS CUR CONo FIN IVDo ONL OUR PHY SAMo TELo"
Server: Microsoft-IIS/8.5
X-MSNSERVER: BN1306____PAP099
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-SqlDataOrigin: S
CTag: aYzpGRjMwNjI5M0Q0MEY5NTI5ITE1OC4yNTc
X-PreAuthInfo: rv;poba;
Content-Disposition: attachment; filename="Test.jpg"
X-Content-Type-Options: nosniff
X-StreamOrigin: X
X-AsmVersion: UNKNOWN; 19.33.0.0
X-MSEdge-Ref: Ref A: 44F40B6FB83547EFBC895911207BDB42 Ref B: 96336B0FC1B608598B549A1CB70C8C59 Ref C: Wed Jan 06 02:22:36 2016 PST
First I thought that maybe it was because the file was small, but trying to download a 250Mb large binary file changed nothing.
I don't complain actually, this would make the program a bit simpler, but I certainly would like to know why the same request works differently with WinHttp*. I suppose I do something wrong, but what??? (Banging my head against my desk.)
There are http libraries that will follow redirects automatically. You send a request, the library receives 302, and decides on its own to go to the redirect location, which then returns a 200.
I've put this in my head section. It appears in the page source in the browser.
<meta http-equiv="Cache-Control" content="max-age=1209600">
However, when I look in the Chrome extension Live HTTP Headers, it says the following.
Cache-Control: max-age=0
Content-Encoding: gzip
Content-Length: 5849
Content-Type: text/html; charset=utf-8
Date: Sat, 05 Apr 2014 04:29:16 GMT
Expires: Sat, 05 Apr 2014 04:29:16 GMT
Last-Modified: Sat, 05 Apr 2014 03:33:19 GMT
The max-age isn't registering. I've emptied the browser cache but it makes no difference.
Any explanations? This is the site, incidentally.
UPDATES:
Firebug similarly records Cache-Control: max-age=0.
Google also makes clear here that max-age overrides the Expires header (which I don't set) and that you don't need both.
When you use tools like Live HTTP Headers, they show you the actual HTTP headers sent by the browser. What they do with meta tags used to simulate HTTP headers is a different issue. We can expect any conflict to be resolved in favor of the actual headers. (This has been normatively specified in HTML specs for Content-Type headers.)
To control cacheing, you should (at least primarily) use server configuration. See Caching Tutorial for Web Authors and Webmasters.
This problem seems related to our server configuration.
I have a video that I want to play with HTML5 video on a website. I use video.js for playback.
The problem is: the video works on my localhost, but it does not work on the production server.
I tried two different servers and they work flawlessly.
I Really need it to work on this specific server (it has a load balancer and more punch to handle the load we are expecting)
I am stumped; I don't know why it does not work on this server, I expect it to be an apache config issue because it works on the other servers.
I looked at the response headers, they are identical (see below). The movie encoding should be allright as well as they are playing on mobile devices on the test servers.
TEST SERVER (works):
HTTP/1.1 200 OK
Date: Tue, 03 Sep 2013 08:16:29 GMT
Server: Apache
Last-Modified: Mon, 26 Aug 2013 09:05:00 GMT
ETag: "baa32-4ceeb0-4e4d60d0e0700"
Accept-Ranges: bytes
Content-Length: 5041840
Cache-Control: public
Content-Type: video/mp4
PRODUCTION SERVER (does not work):
HTTP/1.1 200 OK
Date: Tue, 03 Sep 2013 08:28:07 GMT
Server: Apache
Last-Modified: Mon, 02 Sep 2013 12:18:39 GMT
ETag: "956c0-4ceeb0-4e565927d85c0"
Accept-Ranges: bytes
Content-Length: 5041840
Cache-Control: public
Content-Type: video/mp4
Can anyone give any leads what might be happening here?
Any leads are greatly appreciated.
I found the cause of the problem.
It was related to Request-Range headers.
(See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2 for more information about Request-Range headers)
We had Request-Range headers disabled for security reasons. It turns out that this breaks video playing functionality for IOS devices (desktop and android browsers still worked - tested Firefox and Chrome as well as Android - Chrome)
Allowing Request-Range solved the issue.