CORS middleware not working with HTTPS origin when using --cors-allow-origins

Description
When accessing the WebUI from an HTTPS origin with --cors-allow-origins flag set, CORS errors occur despite the origin being explicitly allowed.

Steps to Reproduce
Start Forge with HTTP and the following settings:
--api --cors-allow-origins=https://new-sankaku.github.io,http://localhost:7860,http://127.0.0.1:7860

*Note: https://new-sankaku.github.io is a comic editing web application built on Github Pages that uses Forge as a backend.
This is a web application that I created.

The CORS settings are logged correctly in startup:
*Note: Confirmed with added logging

CORS allow origins: https://new-sankaku.github.io
Final CORS options: {'allow_methods': [''], 'allow_headers': [''], 'allow_credentials': True, 'allow_origins': ['https://new-sankaku.github.io']}

Try to access from the HTTPS origin
Observe CORS errors in browser console:

Access to fetch at 'http://127.0.0.1:7860/internal/ping' from origin 'https://new-sankaku.github.io' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Expected Behavior
The WebUI should accept requests from the HTTPS origin specified in --cors-allow-origins without CORS errors.

Actual Behavior
CORS errors occur when accessing from HTTPS origins, even though they are explicitly allowed in the configuration.

Additional Context
The issue appears to be related to how the CORS middleware is initialized after removing Gradio's default CORS settings. I've found that rebuilding the middleware stack resolves this issue.

However, my investigation shows that this issue does not occur in the WebUI version, suggesting it might be specific to Forge. The CORS middleware configuration code appears to be the same, and I couldn't identify the difference.

Current behavior summary:
HTTPS (my site) → Forge (HTTP): ✕ (Error)
Local HTML file → Forge (HTTP): ○ (Works)
HTTPS (my site) → WebUI (HTTP): ○ (Works)
Local HTML file → WebUI (HTTP): ○ (Works)

Also, CORS errors do not occur when connecting from HTTP to Forge (HTTP).When cors-allow-origins is removed, CORS errors occur as expected even with HTTP to Forge (HTTP).

Possible Fix
I found that rebuilding the middleware stack after setting up CORS resolves this issue. Here's the modified code:

*:Stable Diffusion WebUI Forge\modules\initialize_util.py
def configure_cors_middleware(app):
from starlette.middleware.cors import CORSMiddleware
from modules.shared_cmd_options import cmd_opts

cors_options = {
    "allow_methods": ["*"],
    "allow_headers": ["*"],
    "allow_credentials": True,
}
if cmd_opts.cors_allow_origins:
    cors_options["allow_origins"] = cmd_opts.cors_allow_origins.split(',')
if cmd_opts.cors_allow_origins_regex:
    cors_options["allow_origin_regex"] = cmd_opts.cors_allow_origins_regex

# Clear existing middleware stack
app.middleware_stack = None
# Add new CORS middleware
app.add_middleware(CORSMiddleware, **cors_options)
# Rebuild middleware stack
app.build_middleware_stack()

This modification ensures that the middleware stack is properly rebuilt after configuring CORS settings.

Start in modules/initialize_util.py at configure_cors_middleware and review how the CORS middleware is initialized after Gradio's defaults are removed. Run Forge with --api and the listed --cors-allow-origins values, then reproduce a request from https://new-sankaku.github.io. Done means the HTTPS origin receives the expected CORS headers while disallowed origins remain blocked.