Closed Bug 1421415 Opened 7 years ago Closed 7 years ago

mixed content blocked after editing URL from http to https

Categories

(Firefox :: Security, defect)

57 Branch
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1420680

People

(Reporter: michael.litwak, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID: 20171112125346 Steps to reproduce: 1. Establish a web page which is served via both http (port 80) and https (port 443). In my case I am using Netty 4.1.6 on Windows 7 64-bit to power my web site. 2. The web page should have a <style> tag with a @font-face section which loads a previously downloaded WOFF font from a relative path (neither http nor https is specified in the URL to the font file). See attached web page source as an example. 3. Launch Firefox and browse to the http URL for your web page. In Developer Tools, the Console will show no problems. 4. Edit the URL in the address bar to https, then press Enter. The Developer Tools Console will show mixed content for the WOFF font being blocked. 5. Now exit completely out of Firefox, restart Firefox, and navigate directly to the https URL for your web page. In this case the Developer Toosl Console will not show any problem with loading the fonts or mixed content being blocked. Actual results: Mixed content is being blocked, but only if you first navigate to the http URL for your page, then edit the URL to specify the https URL for your page. But if you navigate initially to the https URL for your page, no mixed content blocking occurs. Expected results: The WOFF font, which is loaded via a relative path, should load properly and not be blocked as mixed content whether or not the user has previously loaded the same page via http and then edited the address bar to https.
Component: Untriaged → Security
Can you show the output of the webconsole? The webconsole detects Mixed Content in a naive way that doesn't properly categorize all content (bug 908703). But the platform that blocks/allows the subresource loads and updates the UI in the address bar is per spec and shouldn't have the issues you described above. Looking at the webconsole messaging will help determine if this is a new platform bug, or a known webconsole bug.
Flags: needinfo?(michael.litwak)
Adding a screen shot showing the Firefox web console when displaying the web page via an http URL, with no mixed content errors. I'll add another attachment showing what happens when you edit the web address from http:// to https:// and load the page...
This screen shot shows the Firefox web console and the associated mixed content error trying to load the WOFF file from a relative URL. This happens only if you first display the page via http URL, then edit the URL to be https. If you start a fresh Firefox session and navigate directly to the https URL, the mixed content error does not occur.
Flags: needinfo?(michael.litwak)
Possible duplicate of bug 1420680
Seems like a dupe of bug 1420680 Closing unless there is a page we can test, the attachment doesn't replicate.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: