What needs to happen
Sending plain HTTP traffic to HTTPS should be a switch on the proxy. The portal offers it, the API has nothing equivalent, and port 80 is otherwise served as-is with no redirect. A user who needed the behaviour and was working through the API had to build it themselves out of a header match and a redirect rule, which works only because of an implementation detail of how the edge stamps that header before matching.
Why this matters
Anyone managing proxies as configuration rather than through the portal cannot express something the portal presents as a basic option, so the same proxy means different things depending on where it was created. The workaround is fragile: it depends on edge behaviour we have never documented or promised, and it silently stops redirecting if that changes. Serving both schemes with no redirect is also the wrong default for most people putting a site behind us.
Desired outcome
What needs to happen
Sending plain HTTP traffic to HTTPS should be a switch on the proxy. The portal offers it, the API has nothing equivalent, and port 80 is otherwise served as-is with no redirect. A user who needed the behaviour and was working through the API had to build it themselves out of a header match and a redirect rule, which works only because of an implementation detail of how the edge stamps that header before matching.
Why this matters
Anyone managing proxies as configuration rather than through the portal cannot express something the portal presents as a basic option, so the same proxy means different things depending on where it was created. The workaround is fragile: it depends on edge behaviour we have never documented or promised, and it silently stops redirecting if that changes. Serving both schemes with no redirect is also the wrong default for most people putting a site behind us.
Desired outcome