On Tue, Aug 4, 2009 at 7:47 PM, Brion Vibberbrion@wikimedia.org wrote:
On 8/3/09 6:28 PM, Remember the dot wrote:
On Mon, Aug 3, 2009 at 2:16 PM, Brion Vibberbrion@wikimedia.org wrote:
Once we have a cleaner interface for hitting the general pages (without the 'secure.wikimedia.org' crappy single host)
I'm curious...what will this cleaner interface look like? Will we be able to connect securely through https://en.wikipedia.org/?
That's the idea... This means we need SSL proxies available on all of our front-end proxies instead of just on a dedicated location, and some hoop-jumping to get certificate hostnames to match, but it's not impossible.
We did a little experimentation in '07 along these lines but just got busy with other things. :(
A useful data point is that GreenReaper@Wikifur has switched to using protocol relative URLs rather than absolutes (i.e. "//host.domain.com/foo/bar") and had good luck with it. This is an additional data-point beyond the testing I did with en.wp last year. (Last year while doing some ipv6 testing I also tested protocol relatives and determined that all the clients with JS support were unharmed by protocol relatives).
Ironically— the existence of secure.wikimedia.org with insecure images is the only obstruction I see to switching images on the production sites to protocol relatives in order to confirm client compatibility.
(For those following at home: If Wikimedia can use protocol relatives as a global replacement for absolutes to its own domains we can avoid inadvertent secure/insecure mode switching and leaks without having to have two copies of the article cache data and without kludgy on-the-fly rewriting)