On Tue, Aug 4, 2009 at 7:47 PM, Brion Vibber<brion(a)wikimedia.org> wrote:
On 8/3/09 6:28 PM, Remember the dot wrote:
On Mon, Aug 3, 2009 at 2:16 PM, Brion
Vibber<brion(a)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)