Once SSL interface for upload is available (bug 16822), we can either use protocol-relative links or slip in a check in secure.php config to use https:// for these.

n-roeser wrote:

This bug does not only affect Internet Explorer 7, but all web browsers which automatically load images. Some of them do not even display warnings, but transmit insecure content.

Updating summary accordingly.

brian wrote:

(In reply to comment #0)

The logos are being loaded via http://upload.wikimedia.org using CSS such as

<div class="portlet" id="p-logo">

<a style="background-image:

url(http://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png);"
href="/wikipedia/en/wiki/Main_Page" title="Visit the main page [z]"
accesskey="z"></a>

</div>

They are? Not via a CSS stylesheet?

When accessed via the secure.wikimedia.org site with Internet Explorer 7, it
results in a blocking warning "This page contains both secure and nonsecure
items", which needs to be turned off.

Turning off this warning involves going to Tools -> Internet Options ->
Security tab -> Internet zone -> Custom level -> Miscellaneous section ->
"Display mixed content" = Enabled.

I don’t understand what you mean by a “blocking warning” needing “to be turned off”. AFAIK, Internet Explorer 7 and higher also provide a Prompt option, allowing you to keep the warning and still view the items loaded over a non-secure connection.

We are currently in the process of planning a restructure on how we handle secure content. This will be addressed in that update.

John: Is this bug still unresolved?

I dont have IE7 handy, and I no longer use secure.wm.org so I no longer care. I cant reproduce this bug in IE8.

(In reply to comment #6)

I dont have IE7 handy, and I no longer use secure.wm.org so I no longer care.
I cant reproduce this bug in IE8.

Fair enough. I'm going to mark this bug as resolved (as it appears to be).

Anyone is free to re-open the bug if there's still a demonstrable issue.