wp-admin/load-styles.php not serving multiple assets over HTTPS

[ElastisysLars]

My setup is a reverse-proxy SSL-terminated install, where WordPress is served only over HTTP (but the reverse proxy sets the X-Forwarded-Proto header). In my wp-config.php I have the following pertinent settings:

define('WP_DEBUG', false);
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {         
        $_SERVER['HTTPS'] = 'on';                                                                          
}                                                                                                        
define('FORCE_SSL_ADMIN', true); 

I have run in to the interesting issue with WordPress 4.3.1 that my admin area winds up with broken stylesheets when served over HTTPS. I have noted that requests such as:

https://SERVER_GOES_HERE/wp-admin/load-styles.php?c=0&dir=ltr&load=dashicons,admin-bar,wp-admin,buttons,wp-auth-check&ver=4.3.1

result in HTTP 200, but with a zero body length. However, when requesting a single resource:

https://SERVER_GOES_HERE/wp-admin/load-styles.php?c=0&dir=ltr&load=dashicons&ver=4.3.1

I get a reasonable response.

Both types of requests work fine and provide the result one would expect every time when served over regular unsecured HTTP (bypassing my reverse proxy).

Looking a bit further, I noticed that wp-admin/load-styles.php failed, but wp-admin/load-scripts.php did not.

Looking even further, I found that setting

define('SCRIPT_DEBUG', true);

in wp-config.php, I actually get it working, even over HTTPS!

So, something apparently is fishy, but I am neither a WordPress expert nor a PHP programmer. Can someone help me figure this out?

[Jasonheffner]

Hi ElastisysLars,

I'm not one of the developers, but someone in the community like yourself. I saw your ticket and noticed that you were using "===" for comparison instead of "==" . That may make a difference and $_SERVERHTTPS? = 'on' may not be set as you expect.

[ElastisysLars]

I have successfully traced the error to my nginx reverse proxy settings.

To others who experience this type of behavior, the solution is that WordPress assumes that HTTP 1.1 will be used in the wp_admin/load-styles.php logic of building the response. It does not set a HTTP Content-Length header, which is interpreted differently by HTTP 1.0 and HTTP 1.1. What this means in particular is that nginx reverse proxy must be set to use HTTP 1.1, using the following directive in your location definition:

    proxy_http_version 1.1;

You can consult ​the nginx documentation for the meaning of this directive.