This thread was archived. Please ask a new question if you need help.
The html5 player in Mozilla browers triggers the insecure content warning.
I've done everything possible to serve a pure https site. The player built in to the browser seems to break it. Example https://indyradio.info/zero/swr015/swr04-15/32sw0424_15.ogg In Google Chrome, the green bar still shows the site as secure. The only element other than the one file of mine is the mozilla html5 player. This example is served from an https only site with an A+ rating at qualys ssllabs, with HSTS and TLS_FALLBACK_SCSV https://www.ssllabs.com/ssltest/analyze.html?d=indyradio.info&s=126.96.36.199
All Replies (6)
Could you test this to see whether it works around the problem:
(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.
(2) In the search box above the list, type or paste sess and pause while the list is filtered
(3) Double-click the browser.sessionhistory.max_total_viewers preference and edit its value to 0 (that's a zero). (Please don't change any other sessionstore/sessionhistory settings.)
You may need to reload the media using Ctrl+Shift+r to bypass cache.
When I do that, I get a lock as expected. This bypasses one of the sub-features of the "fast back-forward" cache that sometimes causes problems with Firefox recognized cached content as mixed when it actually is not. (E.g., ssl goes mix content on google after pressing back button?)
I don't know whether this has been entered into the bug tracking system. You might be able to work around it from your end by using one of the tricks that prevent caching such as sending a cache-control: no-store header. See: https://developer.mozilla.org/en/docs/Using_Firefox_1.5_caching
If I open the link in a tab them it shows fine for me on Linux. If I refresh the page (F5) then I get a broken connection. Only a refresh and bypass the cache (Ctrl+F5) gives the padlock (you may have to repeat this). I don't know what Firefox stores in the cache that is causing this. The Network log shows three requests, the first two are partial requests.
jscher2000 You're great! Before I do this, let me tell you that my www site does not exhibit the same issue! I just uploaded new content, using jplayer and jquery and there's no problem. Of course, all resources are either local (to my https site) or retrieved via https. (This was not a small challenge with Drupal) I thought the new site would offer fewer "opportunities" for insecure content - why the player is recognized as such baffles me. Then is it really the player? There are only 2 files in the address I gave you. see https://www.indyradio.info
I might not be able to try your work-around until tomorrow, I've got so much pending, but thanks for your kind attention. - dave
jscher2000 - The value of browser.sessionhistory.max_total_viewers was -1 before I reset it to zero, and yes, bypassing the cache with Ctrl+Shift+r did get the lock. I was getting the lock earlier today, but since then managed to get 6 or 8 tabs open (in iceweasel on debian) I was planning to announce the site as "pure https" so this was disconcerting. I can add custom headers, I'll try that.
and cor-el, thanks for testing! I always need testers.
The problem remains! Enabling the cache module in apache and adding the cache directive (as above) did not change anything.
Although I've moved the basic sites around, I made sure the original URL w.the .oggfile still works in case if anyone else would like to test this.
I'm not seeing a "no-store" header for the OGG file:
Request URL: https://indyradio.info/zero/swr015/swr04-15/32sw0424_15.ogg Request Method: GET Status Code: HTTP/1.1 200 OK
Response Headers Δ57ms Strict-Transport-Security: max-age=63072000; includeSubdomains; preload Server: Apache/2.4.10 (Debian) Last-Modified: Sun, 26 Apr 2015 14:52:26 GMT Keep-Alive: timeout=5, max=100 Etag: "60d293-514a1c716be80" Date: Tue, 28 Apr 2015 04:47:03 GMT Content-Type: audio/ogg Content-Length: 6345363 Connection: Keep-Alive Accept-Ranges: bytes