5 ms·

I don't understand this in the context of Wordpress and PHP. As a relic of the CGI spec, a header called "Foo" would be turned into an array index called "HTTP_

by pilif 11y ago

I don't understand this in the context of Wordpress and PHP. As a relic of the CGI spec, a header called "Foo" would be turned into an array index called "HTTP_FOO". For a header called "HTTPS" to be turned into $_SERVER['HTTPS'] as opposed to $_SERVER['HTTP_HTTPS'] would require quite an impressive misconfiguration of the web server which also requires additional work compared to default settings (including possibly even patching PHP itself depending on SAPI).

deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
geofft 11y ago
From the Google bug report (https://crbug.com/505268 https://crbug.com/505268), it looks like WooCommerce was looking explicitly for $_SERVER['HTTP_HTTPS'], and this code was removed when the Chrome behavior was discovered: https://github.com/woothemes/woocommerce/issues/8479 https://github.com/woothemes/woocommerce/issues/8479 So "breaking web applications everywhere" is an exaggeration. It also looks like this is the implementation of the W3 "upgrade-insecure-requests" spec, so "Chrome 44 sending HTTPs header by mistake" is also not true. It's intentional. http://www.w3.org/TR/upgrade-insecure-requests/ http://www.w3.org/TR/upgrade-insecure-requests/ But it sounds like they're going to implement a different header / propose changes to the spec based on real-world feedback like this.
- deleted 11y ago
  [deleted]
- tomsommer 11y ago
  WooCommerce is not the only one doing stupid things with HTTP_HTTPS: https://github.com/search?l=php&q=HTTP_HTTPS&type=Code&utf8=%E2%9C%93 https://github.com/search?l=php&q=HTTP_HTTPS&type=Code&utf8=... Has anyone actually confirmed the problem on a non-WooCommerce site? or a site without bad PHP code?
sarciszewski 11y ago
> For a header called "HTTPS" to be turned into $_SERVER['HTTPS'] as opposed to $_SERVER['HTTP_HTTPS'] would require quite an impressive misconfiguration of the web server which also requires additional work compared to default settings (including possibly even patching PHP itself depending on SAPI). I'd just like to say that this, indeed, appears to be the case. Apache bug most likely.
TazeTSchnitzel 11y ago
> As a relic of the CGI spec, a header called "Foo" would be turned into an array index called "HTTP_FOO". Usually, yes. But CGI has some headers that don't get that prefix, things like "CONTENT_LENGTH". It looks to me like whoever added the HTTPS variable feature to Apache implemented it as an unprefixed header rather than a proper CGI variable, for some reason, and that's the issue. That, or it is a CGI var, but some error in Apache allows HTTP headers to set it.
- pilif 11y ago
  I would have said that content_length is special in that it's supposed to be the actual content length, not the value sent by the client in the header. But I definitely defer to your wisdom as I'm just a user who hasn't done pure CGI in 15 years. As somebody who works on PHP, you are probably infinitely more qualified
  - TazeTSchnitzel 11y ago
    You have a point there. If the request body was weird and lacked the header somehow, I suppose CONTENT_LENGTH would still be there.

by pilif 11y ago

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

geofft 11y ago

From the Google bug report (https://crbug.com/505268 https://crbug.com/505268), it looks like WooCommerce was looking explicitly for $_SERVER['HTTP_HTTPS'], and this code was removed when the Chrome behavior was discovered: https://github.com/woothemes/woocommerce/issues/8479 https://github.com/woothemes/woocommerce/issues/8479 So "breaking web applications everywhere" is an exaggeration. It also looks like this is the implementation of the W3 "upgrade-insecure-requests" spec, so "Chrome 44 sending HTTPs header by mistake" is also not true. It's intentional. http://www.w3.org/TR/upgrade-insecure-requests/ http://www.w3.org/TR/upgrade-insecure-requests/ But it sounds like they're going to implement a different header / propose changes to the spec based on real-world feedback like this.

deleted 11y ago
[deleted]
tomsommer 11y ago
WooCommerce is not the only one doing stupid things with HTTP_HTTPS: https://github.com/search?l=php&q=HTTP_HTTPS&type=Code&utf8=%E2%9C%93 https://github.com/search?l=php&q=HTTP_HTTPS&type=Code&utf8=... Has anyone actually confirmed the problem on a non-WooCommerce site? or a site without bad PHP code?

sarciszewski 11y ago

> For a header called "HTTPS" to be turned into $_SERVER['HTTPS'] as opposed to $_SERVER['HTTP_HTTPS'] would require quite an impressive misconfiguration of the web server which also requires additional work compared to default settings (including possibly even patching PHP itself depending on SAPI). I'd just like to say that this, indeed, appears to be the case. Apache bug most likely.

TazeTSchnitzel 11y ago

> As a relic of the CGI spec, a header called "Foo" would be turned into an array index called "HTTP_FOO". Usually, yes. But CGI has some headers that don't get that prefix, things like "CONTENT_LENGTH". It looks to me like whoever added the HTTPS variable feature to Apache implemented it as an unprefixed header rather than a proper CGI variable, for some reason, and that's the issue. That, or it is a CGI var, but some error in Apache allows HTTP headers to set it.

pilif 11y ago
I would have said that content_length is special in that it's supposed to be the actual content length, not the value sent by the client in the header. But I definitely defer to your wisdom as I'm just a user who hasn't done pure CGI in 15 years. As somebody who works on PHP, you are probably infinitely more qualified
- TazeTSchnitzel 11y ago
  You have a point there. If the request body was weird and lacked the header somehow, I suppose CONTENT_LENGTH would still be there.