Change Details

I propose setting $wgEnableCanonicalServerLink = true everywhere, and setting $wgCanonicalServer to HTTPS on all servers except Chinese language wikis. We did this with uz.wikipedia.org, and so we know with some confidence that it will cause Google to provide links directly to the https website. This will cause most of our traffic to go to HTTPS. I'm filing this to create a place for discussion, rather than as an immediate action item. Before this can be done, the SSL cluster would have to be expanded significantly, assuming Ganglia capacity data is correct -- maybe by a factor of 10. It may be simplest to wait until HTTPS is sent directly to Varnish, but even then, some proper capacity calculations would be in order. This would be an alternative to bug 48402 and a significant step towards bug 47832. Update: >>! In T49832#1240813, @BBlack wrote: > As I've stated before, personally I'd prefer to do the hard redirects before the rel=canonical during the initial rollout process, simply because it's easier to take back in realtime if anything doesn't work out as planned in terms of load and capacity. We already have a process down for this stuff. It's not my place to speak to the rest, but I assure you people are aware and working on it. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=48402 https://bugzilla.wikimedia.org/show_bug.cgi?id=47832

I propose setting $wgEnableCanonicalServerLink = true everywhere, and setting $wgCanonicalServer to HTTPS on all servers except Chinese language wikis. We did this with uz.wikipedia.org, and so we know with some confidence that it will cause Google to provide links directly to the https website. This will cause most of our traffic to go to HTTPS. I'm filing this to create a place for discussion, rather than as an immediate action item. Before this can be done, the SSL cluster would have to be expanded significantly, assuming Ganglia capacity data is correct -- maybe by a factor of 10. It may be simplest to wait until HTTPS is sent directly to Varnish, but even then, some proper capacity calculations would be in order. This would be an alternative to {T50402} and a significant step towards {T49832}. Update: >>! In T49832#1240813, @BBlack wrote: > As I've stated before, personally I'd prefer to do the hard redirects before the rel=canonical during the initial rollout process, simply because it's easier to take back in realtime if anything doesn't work out as planned in terms of load and capacity. We already have a process down for this stuff. It's not my place to speak to the rest, but I assure you people are aware and working on it. **See Also**: * {T50402} * {T49832}

I propose setting $wgEnableCanonicalServerLink = true everywhere, and setting $wgCanonicalServer to HTTPS on all servers except Chinese language wikis. We did this with uz.wikipedia.org, and so we know with some confidence that it will cause Google to provide links directly to the https website. This will cause most of our traffic to go to HTTPS. I'm filing this to create a place for discussion, rather than as an immediate action item. Before this can be done, the SSL cluster would have to be expanded significantly, assuming Ganglia capacity data is correct -- maybe by a factor of 10. It may be simplest to wait until HTTPS is sent directly to Varnish, but even then, some proper capacity calculations would be in order. This would be an alternative to bug 48402{T50402} and a significant step towards bug 47832{T49832}. Update: >>! In T49832#1240813, @BBlack wrote: > As I've stated before, personally I'd prefer to do the hard redirects before the rel=canonical during the initial rollout process, simply because it's easier to take back in realtime if anything doesn't work out as planned in terms of load and capacity. We already have a process down for this stuff. It's not my place to speak to the rest, but I assure you people are aware and working on it. -------------------------- **Version**: unspecified **Severity**: normal **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=48402* {T50402} https://bugzilla.wikimedia.org/show_bug.cgi?id=47832* {T49832}