<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Historically PyPI was only available over either HTTP or unvalidated HTTPS, and over time we’ve been pushing more and more traffic onto HTTPS. In Warehouse the decision was made to *not* redirect “API” URLs from HTTP to HTTPS, but to rather return an error accessing them from HTTP. This is because while logged in views have HSTS to ensure HTTPS in the browser (and with humans manually entering them into the URL bar regularly they are more error prone) APIs which are typically accessed by automated clients with an URL configured or hardcoded typically do not respect HSTS, so if you had a script that did ``curl <a href="http://pypi.python.org/simple/%60%60" class="">http://pypi.python.org/simple/``</a>, it would silently get redirects to https and appear to “work”, but you wouldn’t get any of the security properties of TLS because an attacker would just intercept the request prior to the redirect happening.<div class=""><br class=""></div><div class="">Today I’ve backported this changed to the current production deployment of PyPI, which means that you can no longer access /simple/ and /packages/ over HTTP and you will have to directly go to HTTPS. For most people this should have no effect, because most tooling should be defaulting to HTTPS anyways, however if you’re using a significantly old version of tooling, it may still be defaulting to the HTTP url and will now stop functioning.</div><div class=""><br class=""></div><div class="">The recommended remediation is to upgrade your tooling to versions that support verified TLS connections and which default to the proper HTTPS URLs.</div></body></html>