GeezerVison

To target a different server groups in WikimediaDebug, you can find the appropriate hostname and port number in puppet:/trafficserver/x-wikimedia-debug-routing.lua:

krinkle@deploy1003:~$ curl -i --connect-to ::mwdebug-next.svc.codfw.wmnet:4453 'https://test.wikipedia.org/w/load.php'
HTTP/1.1 200 OK
server: mw-debug.codfw.next-XXX-XXX
…
/* This file is the Web entry point for MediaWiki's ResourceLoader: … */

While you can target mw-experimental in the same way, it is recommended to instead run Curl from the mw-experimental host itself, as this keeps your work contained there and avoids mistakes (such as mistakenly editing files on the deployment server; or testing the wrong data center and not seeing your changes). When you're ssh-ed to mw-experimental you can use Curl like so:

krinkle@wikikube-worker-exp1001:~$ curl -i --connect-to ::$HOSTNAME:4456 'https://test.wikipedia.org/w/load.php'
HTTP/1.1 200 OK
server: mw-experimental.eqiad.pinkllama-XXX-XXX
…
/* This file is the Web entry point for MediaWiki's ResourceLoader: … */

$HOSTNAME automatically refers to the mw-experimental worker in the data center that you're currently logged-in to (Eqiad or Codfw). The same port is used in both data centers.

You can use any URL as-is:

krinkle@deploy1003:~$ curl -i --connect-to ::mwdebug.discovery.wmnet:4444 'https://www.wikimedia.org/'
HTTP/1.1 200 OK
server: mw-debug.eqiad.pinkunicorn-XXX-XXX
…
<!DOCTYPE html>
<html lang="mul" dir="ltr">
<head>
<meta charset="utf-8">
<title>Wikimedia</title>
<meta name="description" content="Wikimedia is a global movement whose mission is to bring free educational content to the world.">
…

This is currently the only way to debug in Beta Cluster, since internal HTTPS is not available there:

user@deployment-mediawiki11:~$ curl -i --connect-to ::$HOSTNAME -H 'X-Forwarded-Proto: https' 'http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page'
HTTP/1.1 200 OK
Server: deployment-mediawiki11.deployment-prep.eqiad1.wikimedia.cloud
…
<!DOCTYPE html>
…

The above example does still go through the Kubernetes host networking layer, and the local Envoy proxy in front of Apache inside each MediaWiki On Kubernetes pod.

There is currently no way to make plain HTTP requests that target Apache directly.^{[citation needed]}

There is also currently no way to target php-fpm directly (i.e. bypass Kubernetes/Envoy/Apache together). You can get close from a deployment server, by using P84273 to open a shell inside the mw-experimental pod (see also T405688). But there is no curl or netcat available within those pods, and the php-fpm socket isn't exposed to the host.^{[citation needed]} etv and only limitation here is that it means you can't debug Apache rewrite rules, and are limited to mw-experimental (going inside the pod for mw-debug or mw-web is for SRE/root only):

To make a plain HTTP requests, which additionally bypasses the local Envoy:

user@mwdebug1002:~$ curl -i --connect-to ::$HOSTNAME 'http://test.wikipedia.org/wiki/Main_Page'
HTTP/1.1 302 Found
Server: mwdebug1002.eqiad.wmnet
Location: https://test.wikipedia.org/wiki/Main_Page

• Host header: Prior to 2015, the more traditional approach of using curl 'http://localhost/wiki/Main_Page' -H 'Host: test.wikipedia.org' was supported, but per T190111 this is no longer possible because connections via "localhost" are handled by a higher priority VirtualHost in Apache that serves responses for the health status checks (not related to MediaWiki).

• FQDN address: Prior to 2019, it was common to workaround the above "localhost" issue by using the internal FQDN (mw0000.eqiad.wmnet) or its internal IP address instead. This is easiest via $HOSTNAME or $(hostname -f), e.g. like curl -i -H 'Host: test.wikipedia.org' "http://$HOSTNAME/w/load.php". While this still works today for HTTP requests, it does not work reliably for HTTPS requests since the web server in question has no certificate for the internal hostname, though this could be bypassed with curl --insecure (or curl -k for short).

• --resolve option: Prior to 2020, other documentation pages recommended --resolve as the main strategy, e.g. curl -i --resolve "test.wikipedia.org:443:$(hostname -i)" 'https://test.wikipedia.org/w/load.php'. This still works perfectly today and is functionally equivalent to the current recommendation with --connect-to. The --resolve option is no longer recommended because it is too easy to misuse and not realize that it was silently ignored. For example, if you specify "resolve" with a different hostname than your URL (with redirects, there can be many host names involved), curl will silently connect to the main production edge for your first and only request, which is easy to miss if you don't enable verbose -v mode and check what server it actually connected to. This can be mitigated by using a wildcard hostname like --resolve "*:443:$(hostname -i)" but that still requires getting the port right, which means over HTTP, it would silently get ignored again, plus it requires the IP address and thus the extra hostname command. The --connect-to option has the benefit of allowing both host and port to be omitted, and supports a hostname as destination (instead of IP address), thus allowing the simpler and more memorable "::$HOSTNAME" form.