Created attachment 282080 [details] Flowchart to describe expected and actual upgrades Steps to reproduce the problem: 1. Generate a page with the following CSP header: `default-src https:; upgrade-insecure-requests` 2. Create a HTML page, protected by the CSP in step 1, that contains an `img` tag with a `src` attribute pointing to an HTTP asset (request A), that can successfully be upgraded to an HTTPS (request B) asset via `upgrade-insecure-requests`. This HTTPS asset should then redirect, via the server, to an HTTP asset (request C). Note that this HTTP asset should work as an HTTP or HTTPS request, but the redirect should specifically be to the HTTP version of the asset. 3. Remove, and possibly flush, any HSTS headers set for the test domain. You can view a test case here: https://test-run-dot-csp-unit.appspot.com/tests/bdfab057-5f90-466f-afdd-0d67ca9c5458. In the test case, http://goo.gl/fDn2aT is upgraded to https://goo.gl/fDn2aT, which redirects to http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150, but *is not* upgraded to https://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150 as I would expect. What is the expected behavior? It is expected that request C should be upgraded to an HTTPS request via `upgrade-insecure-requests`. What went wrong? Request C is not upgraded via `upgrade-insecure-requests` and subsequently blocked by the `default-src https:` CSP directive: Refused to load http://placeholdit.imgix.net/~text?txtsize=33&txt=350%C3%97150&w=350&h=150 because it appears in neither the img-src directive nor the default-src directive of the Content Security Policy.
I forgot to note that this is also a bug in Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=615885), but handled properly in Firefox.
Looks like I already reported this here: https://bugs.webkit.org/show_bug.cgi?id=158389, but forgot about it. I think this report is better than the previous one and am thus going to close the older one.
*** Bug 158389 has been marked as a duplicate of this bug. ***
<rdar://problem/27018807>
Created attachment 326144 [details] Test
@Zack: Are you still able to reproduce this issue? I am unable to reproduce this issue in top-of-tree WebKit using the attached test case (attachment #326144 [details]).
This appears to work properly in Safari 15.5 (and newer).