Tweaking component, has nothing to do with installation.

Bryan.TongMinh wrote:

This just requires a small tweak in Setup.php.

(In reply to comment #2)

This just requires a small tweak in Setup.php.

Right now we use apibase with an http:// url. I'm not quite sure how curl/fopen will react to using that when we're getting the metadata.

There should be a way to configure the "This description is from {foo url}" bit without changing the API calls.

(In reply to comment #3)

There should be a way to configure the "This description is from {foo url}" bit
without changing the API calls.

It is not alone the link to the description. With a https apibase the images are also loaded with https. The images should load also with a protocol relative url, but prop=imageinfo&iiprop=url is giving a explicit protocol. Maybe add an other iiprop which returns a protocol relative url, if the repo wiki support that.

Maybe this can also corrupt the internal cache of api calls.

(In reply to comment #4)

(In reply to comment #3)

There should be a way to configure the "This description is from {foo url}" bit
without changing the API calls.

It is not alone the link to the description. With a https apibase the images
are also loaded with https. The images should load also with a protocol
relative url, but prop=imageinfo&iiprop=url is giving a explicit protocol.
Maybe add an other iiprop which returns a protocol relative url, if the repo
wiki support that.

Maybe this can also corrupt the internal cache of api calls.

The thumbnails are requested by the server, not by the client (unless you're manually configuring $wgForeignFileRepos, but the bug says $wgUseInstantCommons).

I'd recommend simply using https unconditionally here -- an SSL image on a non-SSL page should be perfectly legit.

(In reply to comment #6)

I'd recommend simply using https unconditionally here -- an SSL image on a
non-SSL page should be perfectly legit.

I'm not opposed to this, as long as ops says the https setup can take the load :)

roan.kattouw wrote:

(In reply to comment #7)

(In reply to comment #6)

I'd recommend simply using https unconditionally here -- an SSL image on a
non-SSL page should be perfectly legit.

I'm not opposed to this, as long as ops says the https setup can take the load
:)

Ryan, what are your thoughts on this? It's proposed that starting with MW 1.19 (or 1.20 as the case may be), 3rd-party wikis using InstantCommons will load metadata (api.php on Commons), thumbnails and images (upload.wm.o) over HTTPS unconditionally (right now they're always loaded over HTTP).

Bryan.TongMinh wrote:

What is exactly the usefulness of this? As far as I know thumbnails are cached on the local server, and passed by it to the user. So regardless whether $wgInstantCommons fetches thumbnails over http or https, the user will still get the images over the same protocol as the the rest of the page.

roan.kattouw wrote:

(In reply to comment #9)

What is exactly the usefulness of this? As far as I know thumbnails are cached
on the local server, and passed by it to the user. So regardless whether
$wgInstantCommons fetches thumbnails over http or https, the user will still
get the images over the same protocol as the the rest of the page.

Hmm, true. This would be useful for direct thumbnail fetches but you're right that it would not be useful for direct server-to-server requests.

(In reply to comment #10)

(In reply to comment #9)

What is exactly the usefulness of this? As far as I know thumbnails are cached
on the local server, and passed by it to the user. So regardless whether
$wgInstantCommons fetches thumbnails over http or https, the user will still
get the images over the same protocol as the the rest of the page.

Hmm, true. This would be useful for direct thumbnail fetches but you're right
that it would not be useful for direct server-to-server requests.

Right, assuming you're using $wgUseInstantCommons and not configuring $wgForeignFileRepos yourself, the direct thumb fetches won't happen (hence my comment above about it only affecting the description urls).

Well, it should be configurable, at least. If a site is using instant commons, and is https-only, then it's possible the http connection between the site and commons could be used as an attack vector.

From a load perspective, I think it'll be totally fine. The ssl servers are completely bored right now.

See r107042

Done properly in r107833.