What does the upgrade-insecure-requests policy directive do that a browser's automatic upgrade of mixed content does not?

## Three different upgrades, three different moments This material is full of things that rewrite `http` to `https`, and the interview question is really *which one, and when*: 1. **Autoupgrade** - the browser's built-in handling of **upgradeable** mixed content. No opt-in, no directive, and it touches only an image request with an empty initiator, audio, or video. 2. **`upgrade-insecure-requests`** - a **Content-Security-Policy directive** the author ships. It sets the insecure requests policy on the document's settings object to *Upgrade*, and it applies to **every** insecure request the document makes. 3. Scheme rewriting driven by stored per-host enforcement state, which happens before a request is made at all - a different mechanism on a sibling leaf. This leaf's question is the gap between the first two. ## What the directive adds - **Scope.** Autoupgrade rescues a plate and a recording. The directive also rescues the things that would otherwise be *failed*: scripts, stylesheets, frames, data requests. For an archive whose catalogue records hold absolute plaintext addresses, that is the difference between a viewer that half-renders and one that works. - **Ordering.** The upgrade runs **before** the mixed-content check. By the time the check looks at the request, the URL is already `https`, so the check has nothing to act on and is effectively a no-op. It is worth saying this precisely, because the common misreading is that the directive *allows* mixed content. It does the opposite: it removes the insecure request rather than permitting it. - **Inheritance.** The policy is inherited by nested contexts, so a frame the document creates is covered without its own header. ## The navigation carve-out Not every navigation is upgraded, and the exceptions are deliberate: | Request | Upgraded? | |---|---| | any subresource request from the document | yes | | a form submission from the document | yes | | a nested context's navigation | yes | | a **top-level** navigation to a **different** origin | **no** | The browser keeps an *upgrade insecure navigations set* of the hosts whose policy asked for upgrading, and top-level navigation is upgraded only for a host in that set. The reason is that you may declare a policy for your own documents; you may not silently rewrite where a visitor goes when they leave you. A link out to a plaintext page on someone else's host stays as written. ## The request header, and the caching trap A browser applying this policy also attaches **`Upgrade-Insecure-Requests: 1`** to navigation requests. That is a **request** header - note the direction, because the directive with the same words is delivered on a **response** - and it exists so a server can feature-detect: a client that sends it has declared it can handle being redirected to the secure address, so the server may answer with a redirect instead of the plaintext document. That is where the cache bites. Two clients ask for the same plaintext URL; one sent the header and is redirected, the other did not and gets the document. A shared cache keyed on the URL alone will hand one client the other's answer. The deployment advice is therefore to send **`Vary: Upgrade-Insecure-Requests`** on that response so the cache keys on the header too. ## What it does not buy you 1. **It is not a promise that the upgraded URL exists.** The rewrite changes the scheme and drops an explicit default plaintext port; it does not change host, path or query, and it does not check anything first. If `plates.example.org` serves nothing over `https`, the directive turns a plate that used to fail loudly into a plate that still fails - just after a different request. 2. **It is not a substitute for fixing the records.** Every page load still carries the rewrite, and anything that reads those addresses outside a browser - an export job, a feed, a partner integration - gets no upgrade at all, because the directive is a browser-side document policy. 3. **It is not a relaxation.** Nothing about it makes an insecure request permissible; there is no way to opt a subresource out. ## How to tell which one acted On the console an autoupgraded request and a directive-upgraded request both show an `https` URL you never wrote. The tell is the class of request: if a plaintext **script or stylesheet** arrives over `https` instead of failing, the document's policy is doing it, because the built-in autoupgrade would never have touched it. That single observation is the fastest way to confirm a policy is live on the response you are actually looking at.