Currently Parsoid/JS uses the URLs provided by ApiQueryImageInfo to generate media links, whether <img src> or <source src> or what-have you.

In ApiQueryImageInfo.php there are generated with the following code:

						$vals['thumburl'] = wfExpandUrl( $mto->getUrl(), PROTO_CURRENT );
[...]
				$vals['url'] = wfExpandUrl( $file->getFullUrl(), PROTO_CURRENT );
			}
			$vals['descriptionurl'] = wfExpandUrl( $file->getDescriptionUrl(), PROTO_CURRENT );

			$shortDescriptionUrl = $file->getDescriptionShortUrl();
			if ( $shortDescriptionUrl !== null ) {
				$vals['descriptionshorturl'] = wfExpandUrl( $shortDescriptionUrl, PROTO_CURRENT );

Note the use of wfExpandUrl( ..., PROTO_CURRENT). This makes the protocol match whatever protocol is being used to make the *api request* (ie, http or https). In Parsoid/JS we always use https:// to talk to the mediawiki production cluster, so these always come out as https://. In Parsoid/PHP we are currently debugging on a non-production machine w/ SSL termination, so they are always coming out as http://.

But actual links in the parsed HTML output of the legacy parser use protocol-relative form to match the protocol-relative configuration of $wgServer.

We should probably match this -- there's no reason to hard code a specific protocol into our HTML.

On the PHP side this is easy: remove the wgExpandUrl( ... , PROTO_CURRENT) in Parsoid/extension/src/Config/DataAccess.php so we use the same URLs as MediaTransformOutput::getURL() returns.

It's a little more complicated for the Parsoid/JS side, because we have to reverse-engineer an appropriate URL from the fully-expanded url that API gives us. It's probably easiest just to force Parsoid/JS to always emit protocol relative URLs (strip everything up to and including the first colon) -- and this strategy is probably appropriate for the standalone/api configuration of Parsoid/PHP as well.