5 ms·

Also Australian, The only sensible reason I can think that BOM is not under https is that there are ancient mission critical consuming services somewhere that

Also Australian, The only sensible reason I can think that BOM is not under https is that there are ancient mission critical consuming services somewhere that can't handle the upgrade. For example: a network of regional flood warning alarms that are pulling flood/rainfall data from a feed on the same url. They could have been built in the early 80s, and cant be upgraded. Ignoring them would risk lives etc etc Nevertheless there would be other ways to solve that.

stubish 4y ago
There is no sensible reason, except perhaps money. And using it as an attempt to increase funds or raise the low pay levels hasn't worked and won't work. It is likely to be stuck that way until Chrome stops serving plain HTTP at all from the Internet and someone gets a kick in the bum to fix it, after which a few clicks with Cloudflare or other HTTPS front end provider will sort the problem. And possibly even save money due to caching and not passing on much bad traffic.
dopidopHN 4y ago
Good example, but even so I can think of many way a well directed intern could solve that without touching the code of that things.
- jiggawatts 4y ago
  “Do not redirect from HTTP to HTTPS if source is IP is in list if legacy devices.” There. I’ve solved it. Similarly, a filter based on User Agent would likely also work.
  - dopidopHN 4y ago
    I meant actually solve it by upgrading to HTTPS in a reverse proxy but yeah :)
    - jiggawatts 4y ago
      They're already behind Akamai, and have a valid certificate and the site is reachable on HTTPS... but redirects back to HTTP. That's purposeful incompetence, not an accident, oversight, lack of budget, or anything else that can be excused.
zsims 4y ago
You're just making up things trying to find a reason. HTTP was only invented in 1989, so these imaginary early 80s clients likely don't exist
can16358p 4y ago
Adding HTTPS support doesn't necessarily mean removing HTTP. Even if there was an ancient service that can't handle HTTP, keeping HTTP and adding HTTPS support will do just fine.
cdogl 4y ago
The web uses port 443 for HTTPS, so this example is unlikely to be an issue. Having said that, there are weird and wonderful corporate and government proxy configurations out there that do wacky things. My guess is that their entire system is so tightly coupled that they can't unpick this without a huge amount of work that requires real developers to stick with it and get around it.

stubish 4y ago

There is no sensible reason, except perhaps money. And using it as an attempt to increase funds or raise the low pay levels hasn't worked and won't work. It is likely to be stuck that way until Chrome stops serving plain HTTP at all from the Internet and someone gets a kick in the bum to fix it, after which a few clicks with Cloudflare or other HTTPS front end provider will sort the problem. And possibly even save money due to caching and not passing on much bad traffic.

dopidopHN 4y ago

Good example, but even so I can think of many way a well directed intern could solve that without touching the code of that things.

jiggawatts 4y ago
“Do not redirect from HTTP to HTTPS if source is IP is in list if legacy devices.” There. I’ve solved it. Similarly, a filter based on User Agent would likely also work.
- dopidopHN 4y ago
  I meant actually solve it by upgrading to HTTPS in a reverse proxy but yeah :)
  - jiggawatts 4y ago
    They're already behind Akamai, and have a valid certificate and the site is reachable on HTTPS... but redirects back to HTTP. That's purposeful incompetence, not an accident, oversight, lack of budget, or anything else that can be excused.

zsims 4y ago

You're just making up things trying to find a reason. HTTP was only invented in 1989, so these imaginary early 80s clients likely don't exist

can16358p 4y ago

Adding HTTPS support doesn't necessarily mean removing HTTP. Even if there was an ancient service that can't handle HTTP, keeping HTTP and adding HTTPS support will do just fine.

cdogl 4y ago

The web uses port 443 for HTTPS, so this example is unlikely to be an issue. Having said that, there are weird and wonderful corporate and government proxy configurations out there that do wacky things. My guess is that their entire system is so tightly coupled that they can't unpick this without a huge amount of work that requires real developers to stick with it and get around it.