On Thu, Dec 27, 2012 at 1:39 PM, Marco Fleckinger <marco.fleckinger(a)wikipedia.at> wrote: Are you suggesting we use different nonstandard ports for each different wiki/language combo that resides on the same IP ? -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/

On Thu, Dec 27, 2012 at 2:37 PM, Marco Fleckinger <marco.fleckinger(a)wikipedia.at> wrote: I guess that is theoretically possible with a more intrusive load balancer in the middle. We need the HOST information from the http header to be added as we have our varnish caches serving multiple services, not one(or more) per language/project combo. I'm pretty sure that lvs doesn't have this ability (which we use). Some large commercial load balancers have the ability to rewrite some headers, but that would be a pretty intensive operation (think lots of cpu needed, since it needs to terminate SSL and then rewrite headers) and would probably be expensive. If you have another way you think we can do this, I am all ears! We may want to move this discussion to wikitech-l as all the technical discussions probably bore most of the people on wikimedia-l Leslie -- Leslie Carr Wikimedia Foundation AS 14907, 43821 http://as14907.peeringdb.com/

Thank you everyone for your help, and I especially appreciate Sumanah for setting up the bug and making the RT ticket happen. Unfortunately, I cannot track the progress of the RT ticket, but I am sure someone will keep us posted on the Bugzilla bug or on this list. Eternal gratitude to everyone involved! Regarding the discussion about the IP, here are my thoughts, but maybe I am missing a number of the technical intricacies here: I am not sure if I understand correctly, but having access through the IP does not seem to improve the situation. Remember that access through https is perfectly possible. So for anyone who really wants to access the wiki and knows about the https-access, they can. The problem are those people that do not know about it. There are no people coming to the Uzbek Wikipedia through search engines, because they link to the http-protocol version of the URLs. That is why making the https-Version canonical and thus the addresses the search engines eventually point to much more useful. One could make the IP-Adress directly canonical -- otherwise setting up this extra-IP would not bring any advantage -- and thus avoid DNS, but this is not required to resolve the current problem, and it sure would not be very pretty. Also, IP-banning a single IP through an ISP is all but hard for an ISP. And anyway, it would need to be configured to setup a canonical URL, which is the currently suggested next step anyway. Therefore I would suggest to refrain from setting up a specific IP (besides the technicality of having too few IPs around), at least for now, and concentrate on canonizing the HTTPS protocol (as summed up in the Bug). Thank you again! On Fri, Dec 28, 2012 at 3:05 AM, John Vandenberg <jayvdb(a)gmail.com> wrote: