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.