https://bugzilla.wikimedia.org/show_bug.cgi?id=56938

--- Comment #29 from jeremyb <bugzilla+org.wikime...@tuxmachine.com> ---
(In reply to Philippe Verdy from comment #28)
> And
> where's then the link on the new WMUK site (or on Meta) to track the other
> discussions that may be needed outside this bugtracker which currently asks
> for "patch review"?

I don't know, feel free to ask the WMUK team directly. This bug definitely
isn't the place. (but you could put a pointer to that place here)

> Do you think that my suggestion in comment 18 is overlong when it includes
> also the warning about the possible caveat (that should probably not be
> forgotten during the migration of the discussed chapter website)?

That makes me wonder again if you're really clear that the migration is already
essentially complete? (the last thing to wrap it up is this bug)

Maybe comment 18 was too long. Hard to say because I don't know what you meant
for some parts. (see below for some questions) That may be an example where
length can be somewhat mitigated by clearly delineating some sections from
other. Like you would use <h#> headings in HTML. In this case some readers
could ignore the caveats if they're uninterested in doing a CNAME.

(In reply to Philippe Verdy from comment #18)
> Why couldn't this be a DNS redirect (CNAME) of an HTTP permanent redirect
> that requires performing two separate sessions to separate servers ?

Either way is 2 separate requests (what does session mean?) and probably 2
separate connections. [[HTTP pipelining#Implementation status]] currently
indicates that most proxies and browsers (except Opera) either don't support
pipelining or have it disabled by default. Also, maybe some implementations
will make a different connection per hostname? (idk what the specs have to say
about that)

So (even assuming the CNAME route) most (all?) requests by actual users for the
old domain will be done without pipelining. (we don't care about perf for
googlebot, right? and if this *is* about perf maybe WMF perf is *better* than
WMUK?)

We can safely discard the 2 sessions argument.

> No more trafic reaching WMF servers (except to its third-party DNS hosting
> service), all the trafic goes directly to WMUK.

Why does this matter? That should be answered up front. (I'm not necessarily
saying it doesn't. but if we're going to spend cycles figuring out a more
complicated solution than what was originally requested (comment 0) there
should be some reason for it)

For the record, WMF has no 3rd party DNS hosting. (All DNS is served from WMF
boxes in WMF racks. Where did that idea come from?)

> Caveat: the WMUK webserver would have to accept HTTP queries whose "Host:"
> header still uses the former domain name, and to solve it correctly, would
> host the HTTP redirect itself (so that clients get informed of the change of
> domain name and can fix their URLs) to specify the correct "Host:" value to
> use.
> 
> The HTTP redirect performed on WMUK servers themselves will be necessary if
> WMUK wants to be accessible via HTTPS, in order to validate their own
> security certificate (which cannot be issued by them for a subdomain of
> wmimedia.org owned and controled by the WMF).

I have no idea what that last paragraph means.


FWIW, there's plenty of precedent for using the main WMF cluster for
redirect-only domains pointing to off-cluster services and that trend is
increasing. See e.g. bugzilla.mediawiki.org, doc.mediawiki.org,
labs.wikimedia.org, it.wikimedia.org, hu.wikimedia.org, ch.wikimedia.org, etc.

There's only one active precedent I can find for CNAME from a chapter country
code subdomain of wikimedia.org to an off-cluster target. That's cs/cz which
both have the same target which doesn't even listen to port 443 at all.

If you do care at all about HTTPS clients hitting the legacy hostname then I
advise against a CNAME. (especially because AFAIK there's not an actual
argument in favor of the CNAME. Please point it out if one does exist)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to