On Tue, Aug 4, 2009 at 7:47 PM, Brion Vibber<[email protected]> wrote: > On 8/3/09 6:28 PM, Remember the dot wrote: >> On Mon, Aug 3, 2009 at 2:16 PM, Brion Vibber<[email protected]> 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 greenrea...@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) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
