I'm having some trouble getting Firefox to cache an exe file that we have on our web site. If I download it with IE or Chrome and start the download a second time then the second download finishes immediately but with Firefox it downloads everything from the start.
I've attached screenshots from the network tab in Chrome and Firefox. Notice that both receive HTTP Status Code 200 but Chrome says (from cache). What response headers do I need to add to make Firefox cache it?
Chrome:
Firefox:
Here's the url if you wish to try downloading it it yourself: https://dlud0tbph7s2n.cloudfront.net/Production/Windows/DegooSetup-Production-1.0.1052.exe.
You can check if the exe file is cached by looking in 'about:cache' or using a tool like HttpWatch.
Your EXE file is not getting cache. In older versions of Firefox that could be due to the file exceeding the maximum size for a single cache entry. By default, the maximum entry size is now 50 MB. You can check this by looking at 'browser.cache.disk.max_entry_size' in 'about:config'.
The problem might be caused by the very large value of max-age that you have set - 2000000000 seconds is about 63 years. The HTTP spec only recommends using periods up to one year and some browsers refuse to cache for very large values of max-age:
https://stackoverflow.com/a/25201898/66911
The recommended maximum value of max-age is 31536000 seconds or less.
Related
I've made an analysis in OBIEE which searches for a file in the analyticsRes folder on the server.
The column formula looks like this : ''||"Afdeling"."Afdeling"||''
It downloads the correct file according to the filter you're applying on the dashboard. This works perfectly fine, except for browser cache.
We found out that the browser caches the file behind this link, so when a new one is put on the server, the old one still gets downloaded.
Can I disable browser cache for this analysis only OR for the whole dashboard (is this a good idea?) so that users will always download the newest version of the file?
I've tried adapting the instanceconfig.xml file according to this:
<ServerInstance>
<Cache>
<CatalogXml>
<!-- Remove from the cache everything older than N minutes -->
<MaxAgeMinutes>240</MaxAgeMinutes>
<MaxLastAccessedSeconds>14400</MaxLastAccessedSeconds> </CatalogXml>
</Cache> </ServerInstance>
But this isn't the cache used for my issue.
I expect the analysis to be able to always look on the server for the file, but now it caches the file for a long time. It would be also okay if the cache would expire after 24h.
Thanks!
No. You have zero influence on browser cache from inside OBIEE. The cache above is OBIPS cache, not browser cache.
I have Disable cache tick removed and still request is made on each video loop iteration(Only on chrome).
What Initiator: Other mean in chrome inspector network section? First time the video is loaded from the host, but after that all requests are loaded from Other.
Each iteration video size is the same, not (from cache). Is that mean the browser download it every time?
Can it be avoided somehow without saving the video in localStorage(I saw it in similar question), because this solution will not work in private browser mode and localStorage have size limit?
UPDATE
With Disable cache checked
Without Disable cache checked
UPDATE
Bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=680063
The meaning of this is that another process than Chrome initiated the request:
Some other process or action initiated the request, such as the user
navigating to a page via a link, or by entering a URL in the address
bar.
In the case of Chrome, video is decoded using ffmpeg which likely is this other process. The process is likely reopening the file from the cache which is why the request is initiated, or, the cache only holds the latter part (or max content length in sum) of the file in case the file is large and has to re-stream parts of the content over again - though, you state that when cache is disabled this doesn't happen.
localStorage has a very limited size and is not very suitable for storing video data (it can only hold strings so video must be encoded as mime-64 which increases the size 33% + each char takes up two bytes due to unicode).
A better alternative would be to use IndexedDB - this can hold much larger data as well as store the data in binary format (Blob). But it comes with an initial limit as with localStorage but contrary to the latter method you can request a larger size which the user need to confirm. I haven't tested, but I would assume you will run into the same limitations with private mode as with any other storage mechanism.
Yesterday I had the same issue. I found that Chrome's tab crashes after a couple of minutes. It looks it happens only when Disable cache is checked, but if this still bugs you, you can store the video into the local storage. More code in this answer.
I'm trying to make an offline webapp for Mobile Safari mainly. I have my .appcache file set up and it's working fine until I add a line for a .mp4 -file (52 mb). Even Desktop Chrome will fail appcaching the app 'cause of the file - it gives an error:
Application Cache Error event: Resource fetch failed (-1)
And because that fails, the whole appcaching fails.
Using a http sniffer (HTTPScoop) I found out that around 30 mb the downloading of the mp4 stops, and gives "Reset by peer" -error.
Does it have something to do with Apache, with the browser, the ISP or what?
According to one of the people who posted something here, Chrome has a 260mb total appcache size limit and about 32mb per-file limit (which is about when you said the download stopped). I don't know about other browsers, but in Chrome you can fix this by creating a chrome app. It seems inconvenient and annoying, but it is the only way to increase that limit. Not sure if that info is up-to-date because that link is a few years old, but that seems to be the case.
I am trying to store a mp4 video file (rather small ~ 2.5MB) in the local app cache.
Manifest looks like:
CACHE MANIFEST
viddy.mp4
Chrome (22.0.1229.94 m) will log the following in the console:
Creating Application Cache with manifest http://example.net/cache.manifest
Application Cache Checking event
Application Cache Downloading event
Application Cache Progress event (0 of 1) http://example.net/viddy.mp4
Application Cache Error event: Resource fetch failed (-1) http://example.net/viddy.mp4
When I click the link right next to the Error it's opening the file quite fine.
My manifest is served with the correct MIME-type (I'm using the HTML5 Boilerplate .htaccess-file) and the video is served Content-Type:video/mp4
Is my file too big? I am perfectly able to cache a 1MB image this way, so I thought filesize should not be a problem? Safari on desktop and iPad does cache the video just fine.
Remark: I have seen this question but it does not cover my problem as the solution seemed to be something Python-related.
Chrome does not allow data to be stored in Incognito Mode.
I experienced similar problem and this is how I solve it. In this case Chrome does not give any helpful information about error. I've tried to load same page in Safari (Mac, but Windows should work as well), and I got description, that response for specified resource returns 302 (Redirect) and HTML5 Application Cache cannot handle it.
In your case it might be the same, but I'd suggest you to enable the sniffer and see, what response you get from your resource. If it's different than 200 - you figured the issue.
P.S. I've cached files up to 32 MB without any problems.
I have been working on a jquery plugin that uses a HTML5 audio player () to play back mp3's. I noticed that in various browsers multiple GET requests were made for the same MP3 file when the audio player was loaded.
I created a simple standalone HTML file to test this out.
<html>
<head></head>
<body>
<audio controls src="http://localhost:5000/files/one.mp3" type="audio/mp3"></audio>
<body>
<html>
When opening the page in OS X Safari 5.0.1, I saw the following logs from my web server (3 GET requests):
>> Thin web server (v1.2.7 codename No Hup)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:5000, CTRL+C to stop
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0022
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0012
127.0.0.1 - - [17/Aug/2010 11:09:32] "GET /one.mp3 HTTP/1.1" 200 4030432
0.0010
Note, the requests are for "GET /one.mp3" and not "GET /files/one.mp3" because my Thin web server is running off a prefix of /files.
When opening the same HTML file in OS X Chrome, I saw 2 GET requests for /one.mp3.
When opening the same HTML file in OS X Opera, I saw 1 GET request for /one.mp3.
What is the reason for the multiple GET requests for a single files? The bandwidth on my server is limited and I throttle connections at 75KB/s (thats HTTP connection, not user). My worry is if Safari is making 3 HTTP connections to download (stream) a single mp3 file, it will reduce the number of concurrent users my server can handle.
Is this something I should be worried about in terms of performance/bandwidth? Also, I am curious as to why certain browsers make multiple requests for the same file, while other do not.
In the case of Firefox, three requests are made for audio. This is to support playback regions and seeking of media files that aren't downloaded yet. It's essentially downloading the file and determining it's duration in three chunks. The following was given as an explanation when this behavior was reported to Mozilla as a bug:
The first GET reads the first chunk of the ogg file. From this we can ensure it's a valid ogg etc. The data downloaded should be cached by Firefox.
The second GET: Unfortunately Ogg files don't contain their duration, so we terminate the initial download, and we seek to the end of the Ogg file and read a bit of data to extract the time duration of the media.
The third GET: After we've ascertained the duration of the media, we'll resume download of the media. We don't need to redownload data which is already cached, so we resume from wherever the previous download stopped.
Though this explanation only applies to Firefox, you can presume that similar methods are used by webkit browsers as well.
I don't think you should be concerned about this affecting the number of concurrent users. If your server logs showed the timestamp in milliseconds you would see that the three requests fire consecutively and that each request is cancelled before a subsequent request is made.
Is it possible that Safari is making additional requests to fetch metadata? Try different values of the preload attribute to see if it makes any difference:
preload="none" - no data is prefetched (shouldn't see any GETs)
preload="metadata" - basic metadata like duration, bit rate, sample rate, etc. is prefetched (should see one GET)
preload="auto" - the whole file is prefetched (may see multiple GETs)
See http://dev.w3.org/html5/spec/Overview.html#attr-media-preload for a full description of this attribute.