Gutenberg editor fails to load styles and images for backend only when hosting wordpess as an Azure App Service

When doing a install of wordpress app service in Azure always results in a unusable gutenberg editor. Typically I always enable azure frontdoor or cdn and blob storage but from my testing this bug also happens without ANY additional features added. I have not determined the exact cause of why Azure app service is the only hosting environment that has this issue but things I have noticed that differ with Azure from traditional hosting and even other hypescalers such as AWS is Azure app services utilize environment variables and host variables for each of the values defined in the wp-config.php. An example of their out of the box config is as follows:
```
getMessage());
}
}

/** The name of the database for WordPress */
define('DB_NAME', $connectstr_dbname);

/** MySQL database username */
define('DB_USER', $connectstr_dbusername);

/** MySQL database password */
define('DB_PASSWORD',$connectstr_dbpassword);

/** MySQL hostname */
define('DB_HOST', $connectstr_dbhost);

/** Database Charset to use in creating database tables. */
define( 'DB_CHARSET', 'utf8' );

/** The Database Collate type. Don't change this if in doubt. */
define( 'DB_COLLATE', '' );

/** Enabling support for connecting external MYSQL over SSL*/
$mysql_sslconnect = (getenv('DB_SSL_CONNECTION')) ? getenv('DB_SSL_CONNECTION') : 'true';
if (strtolower($mysql_sslconnect) != 'false' && !is_numeric(strpos($connectstr_dbhost, "127.0.0.1")) && !is_numeric(strpos(strtolower($connectstr_dbhost), "localhost"))) {
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);
}

/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define( 'AUTH_KEY', 'asdfasdfasdfdasdfasdfasdfasdfasfsadfsa' );
define( 'SECURE_AUTH_KEY', 'asdfdsafasdfasdfasdfasdfasdfasdfasdfsadfsad' );
define( 'LOGGED_IN_KEY', 'asdfasdfasdfsadfsadfdsafsadfsadfasdfasdfasdf' );
define( 'NONCE_KEY', 'asdfasdfasdfasdfasdfsadfdsafsadfsdafsdafsdads' );
define( 'AUTH_SALT', 'asdfasdfasdfsadfasdfsadfsadfasdfasdfsadfsadfsdafsadfsd' );
define( 'SECURE_AUTH_SALT', 'asdfsadfasdfadsfasdfsdafsdafsadfasdfdsafdsfdsafdsafdsaf' );
define( 'LOGGED_IN_SALT', 'sdfsadfdsafsadfasdfdsafdsafdsfdsfdsfdsafdsafdsafdsa' );
define( 'NONCE_SALT', 'asdfasdfdasfdsafdasfdsafadsfasdfdsafdsafdsafdsafdsafdsafsad' );

/**#@-*/

/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = 'wp_';

/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the documentation.
*
* @link https://wordpress.org/support/article/debugging-in-wordpress/
*/
define( 'WP_DEBUG', false );

/* That's all, stop editing! Happy blogging. */
/**https://developer.wordpress.org/reference/functions/is_ssl/ */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS'] = 'on';

$http_protocol='http://';
if (!preg_match("/^localhost(:[0-9])*/", $_SERVER['HTTP_HOST']) && !preg_match("/^127\.0\.0\.1(:[0-9])*/", $_SERVER['HTTP_HOST'])) {
$http_protocol='https://';
}

//Relative URLs for swapping across app service deployment slots
define('WP_HOME', $http_protocol . $_SERVER['HTTP_HOST']);
define('WP_SITEURL', $http_protocol . $_SERVER['HTTP_HOST']);
define('WP_CONTENT_URL', '/wp-content');
define('DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST']);

/** Absolute path to the WordPress directory. */
if ( ! defined( 'ABSPATH' ) ) {
define( 'ABSPATH', __DIR__ . '/' );
}

/** Sets up WordPress vars and included files. */
require_once ABSPATH . 'wp-settings.php';
```
As you can see they utilize $_SERVER and getenv() to reduce putting hard coded values in and seems pretty standard like it should work and allows extra security and flexibility surrounding the domain. However, the gutenberg editor is completely unusable and is missing styles and images. I was able to get the styles to work by modifying the default wp-config .php line as shown:

```
define('WP_CONTENT_URL', '/wp-content');
```
to
```
define('WP_CONTENT_URL', $http_protocol . $_SERVER['HTTP_HOST'] . '/wp-content');
```
This fixes the styling issue so it pulls straight from the content folder via an absolute path. However this for some reason does not fix the images not loading on the gutenberg editor itself. I have tried endlessly with no solution to fix this issue. I tested this on a different web host and I was able to replicate this strange behavior in Azure by setting the values of WP_HOME and WP_SITEURL to '' as such:
```
define('WP_HOME', '');
define('WP_SITEURL', '');
```
I did find that if I install this one particular third party block editor generateblock it does magically fix the issue for styles and images for desktop view only. If you switch to tablet or mobile everything is broken as usual.

I am struggling with this and hoping there is a solution other than "switch away from Microsoft Azure app services...." as I have invested in some 3 year reservations as well as migrated multiple sites to azure and this should work in this environment a well. To recreate this issue I recommend just spinning up a quick azure wordpress app service (check azure front door just to compare) and you will see regardless it will fail for the gutenberg editor for desktop, tablet, and mobile view and be unusable.

I have included a few pics to show the issue but the best bet to solving is doing a fresh deployment to recreate: