• Brian Boorman (unregistered)

    function is_frist() { if ( isset($_COMMENT['FRIST']) ) return true; }

  • Abigail (unregistered)

    If you want to be picky about the elseif part, running something other than a web server on port 443 isn't a problem for this code. This code won't fail because you're running your mail or FTP server on that port, because then the code won't get executed if something starts knocking on port 443.

    It will fail if you're running your SSL web server on any other port than 443 and it's also failing the first test. Or if you're running a web server on port 443, and it's not SSL enabled.

  • guest (unregistered)

    I was going to say "Why don't you just check if the request url starts with https, that's unambiguous", but a quick google suggests that PHP doesn't have the equivalent of Flasks request.url. That's your real WTF right there.

  • RLB (unregistered)

    The isset() calls are strictly necessary, unless you enjoy having error logs full of "PHP Notice: Undefined index: whatever".

  • Burner (unregistered)

    Looks like busy work for a badly misbehaving coder...

  • Ollie Jones (unregistered)

    WordPress's code base has an extraordinary burden to carry. Because it supports 30-some-odd percent of the web sites on the internet, it has to run on all kinds of mondo-bizarro server hardware and software. For example, the majority of sites run using database software versions that are past end-of-life. Various budget hosting providers offer genuinely low-end setups, and they don't maintain them. And, some hosting providers use super-high-end RAM-flush servers with all sorts of optimized software. To top it off, it's php. php is like the 50 First Dates movie: it loses its memory with every new page or API call it services.

    Still, WordPress auto-updates itself with every new release (6.1 rolled out yesterday), and sites don't die.

    Look, dear colleagues: WordPress is the way engineering works. Robust, handling multiple weird edge cases. Yeah, some if it's ugly. And because it's php, the ugliness is hard to encapsulate. But it works.

  • (nodebb)

    The only sliver of a reason I can imagine is that at one time in pre-history PHP messed up setting HTPPS correctly, and that wordpress@2022 still has the resulting .work-around available (mandatory for everyone) because there may be one user in the world who still runs that particular version of PHP on their 8086 booted from their floppy disk. Even so (and perhaps especially so), it's still a WTF.

  • Tim Ward (unregistered)

    When I'm forced to write workarounds like that I actually bother to put in the comments - "workaround for bug xxx in version Y of Z" - so that someone in the future can, if they can be arsed, strip out the crap code when it's no longer needed.

  • Anders (unregistered)

    This won't work nicely if there's a load balancer that terminates SSL/TLS. But hey, who would run a Wordpress site for anything that would require good load balancers?

  • löchleindeluxe (unregistered)

    Ugh, that one… don't get me started. Because it's still missing half the cases. (TLS termination on load balancer is a thing. Your app simply does 👏 not 👏 know 👏 how it gets shipped back. And this doesn't even look at X-Forwarded-Proto or Forwarded headers or REQUEST_SCHEME. Probably a good thing, because REQUEST_SCHEME is out of sync with HTTPS in certain undocumented, but once very useful httpd configurations involving <VirtualHost *:80 *:443>. Nowadays, send HSTS ,CSP upgrade-insecure-requests and just have a hard redirect on port 80.) OK, got me started. Anyway, I don't think this one gets called a lot anymore, since Wordpress has an actual config variable for its base URL that it can/will/should base everything off of.

  • peanutlord (unregistered)

    Seems like IIS is setting $_SERVER['HTTPS'] to off instead of an empty value... Microsoft...

  • Joe Hall (unregistered) in reply to guest

    Once you realise how an http request is actually sent to the http server you'll realise that the original URL, that might have been used to initiate the request, is not passed to the server. Therefore, any URL made available to/by server side software, like flask, is actually reconstructed based off a range of facts [and sometimes assumptions] available in that environment. Path and query is past intact in the first line of the request. Host name is past as an header. I'm not sure whether a specified port number will be there too.

    Port number will be know to the application handling transport layer of the connection to the client. If the client socket is terminated directly to the webserver, it will know the port which the client requested. But it won't know whether it's a direct connection, or a reverse proxy, e.g. load balancer is used in between. As a workaround there are some common headers which are added for such proxies to pass along such knowledge. Similarly, the s of https is also only known to application handling the transport layer. So, in conclusion, PHP must similarly rely on being provided with these facts and assumptions in a standardised manner. Since there's no formal standard for such, doing the job of putting it all together and exposing a 'factual' URL is just too ambiguous...

  • xtal256 (unregistered)

    I remember there was a website where the login UI showed a green "HTTPS" in the header to re-assure you that you were logging in to a https site. And it showed that even if you went to the http version.

    The worst part, it was the anti-virus company Avira!

  • (nodebb) in reply to guest

    That won't work, way too many programs and systems helpfully decide that when you said HTTP what you really meant was HTTPS, so while HTTPS probably means HTTPS, HTTP doesn't necessarily mean HTTP.

  • Álvaro González (unregistered) in reply to guest

    It has $_SERVER['REQUEST_SCHEME']. No URL parsing needed.

  • Silas (unregistered)
    Comment held for moderation.
  • thiyashborewells (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Tim Ward

    When I'm forced to write workarounds like that I actually bother to put in the comments - "workaround for bug xxx in version Y of Z" - so that someone in the future can, if they can be arsed, strip out the crap code when it's no longer needed.

    And thereby find the 12 other components that have sprung up in the interim relying on the same behaviour.

  • Bartech (unregistered)

    Your right it was done to accommodate for some servers initially this was one liner return ( isset($_SERVER['HTTPS']) && 'on' == strtolower($_SERVER['HTTPS']) ) ? true : false; I found change history it's here https://core.trac.wordpress.org/ticket/8641

Leave a comment on “On SSL”

Log In or post as a guest

Replying to comment #:

« Return to Article