Challenge 3: Diagnose a Mixed-Content Block — Possible Solution
====================================================================

THE PROBLEM
------------
A page loaded over "https://example.com" tries to open:

  new WebSocket("ws://example.com/chat")

...and the browser silently blocks the connection.

WHY THIS HAPPENS
-----------------
This is exactly the "mixed content" restriction from the HTTPS/TLS
course, applied to WebSockets instead of images or scripts. A page
served over HTTPS has an encrypted, tamper-proof connection to the
server — the browser will not let that secure page then open a SECOND,
UNENCRYPTED connection (plain "ws://") to fetch or send data, because
doing so would silently undermine the security guarantee the padlock is
supposed to represent. A network attacker who can't touch the HTTPS
traffic could still intercept or tamper with the plaintext "ws://"
traffic, so browsers block the insecure connection outright rather than
letting the page create a secure/insecure hybrid without the user's
awareness.

This is the same rule that blocks an HTTPS page from loading an
"http://" image or script — WebSockets just have their own protocol
scheme (ws/wss) that mirrors http/https, and mixed-content blocking
applies to it identically.

THE FIX
--------
  new WebSocket("wss://example.com/chat")

Simply use "wss://" instead of "ws://" — this runs the WebSocket
connection over TLS, matching the security level of the HTTPS page
it's being opened from. There is no way to "allow" a plain ws://
connection from an https:// page through browser settings or server
configuration — the fix is always to serve the WebSocket endpoint over
TLS and connect with wss://.

WHY THIS WORKS
--------------
- Browsers apply the mixed-content rule based on the SCHEME of both the
  parent page and the resource/connection being opened, not on anything
  configurable per-site — an https:// page can only open wss://
  WebSocket connections (or same-origin ws:// exceptions don't exist for
  this in modern browsers the way they might for some other mixed-content
  categories).
- This also means a WebSocket server needs to actually support TLS (a
  valid certificate, same as any HTTPS server) before wss:// will work —
  it's not just a URL prefix change, the server side has to be genuinely
  configured for it, which in practice means putting the WebSocket
  server behind the same TLS termination (e.g. nginx, a load balancer)
  already used for the site's HTTPS traffic.