I am wondering whether it is by omission or purpose that http://noc.wikimedia.org/ does not have https:// available?
Version: unspecified
Severity: enhancement
I am wondering whether it is by omission or purpose that http://noc.wikimedia.org/ does not have https:// available?
Version: unspecified
Severity: enhancement
(In reply to comment #1)
Why does it really need it?
I was about requesting an interwiki link to the server to be added, and I presume that there is a requirement to note or configure relative urls or otherwise. If that is not the case, okay; there is no information about to assist those of us who are clueless.
(In reply to comment #1)
Why does it really need it?
Oh, and I did ask in #wikimedia-tech prior, and it was suggested that I add a request and to let the decision lie with "those who make such decisions."
Quickly approaching a https://en.wikipedia.org/wiki/Zero_One_Infinity problem here. Either all *.wikimedia.org domains should support https or none should. Allowing an arbitrary set is a bad idea. History tells us this (similar issues have arisen with *.wikimedia.org login cookies).
Else, perhaps a more systematic approach can be taken? The large underlying motivation to making the wikis support https is that there are user login credentials being passed in headers. For noc.wikimedia.org, it's all public files with no user auth, as far as I know. I'm not sure why it would need https support.
(In reply to comment #5)
Else, perhaps a more systematic approach can be taken? The large underlying
motivation to making the wikis support https is that there are user login
credentials being passed in headers. For noc.wikimedia.org, it's all public
files with no user auth, as far as I know. I'm not sure why it would need https
support.
I believe it's our intention to support HTTPS for all of our domains, but I'll leave the authoritative answer to Ryan.
I don't think it's necessary to have this argument every time a bug is submitted for services that don't have https, so... For every service we have, if it is feasible to do https, we should do https.
Please continue to submit bugs for services which are missing https.
(In reply to comment #8)
Please continue to submit bugs for services which are missing https.
Are you sure individual bugs make sense here? Something more systematic seems saner.