GNOME Bugzilla – Bug 703063
HTTPS pages still refer to plain HTTP resources
Last modified: 2013-06-28 18:04:24 UTC
Some old API reference pages still loads their resources over plain HTTP and since Chromium blocks the CSS requests they rendering is quite ugly, see https://developer.gnome.org/glib/2.29/glib-GVariant.html The same issue happens on the ml archives, but since only some minor resources are still HTTP-only only a warning is shown near the SSL icon, see http://mail.gnome.org/archives/gupnp-list/2013-April/msg00004.html.
The first link was referencing to an old glib release. I removed all the odd glib releases from developer.g.o as fredp suggested me to do. You were getting a wrong rendering on those pages cause they weren't rebuilt anymore. About the mail archives, I did apply a good bunch of changes and you can see the effect here: List archives: https://mail.gnome.org/archives/commits-list/ Month view: https://mail.gnome.org/archives/commits-list/2013-June/thread.html Single message: https://mail.gnome.org/archives/commits-list/2013-June/msg06776.html It'll take a bit for all the lists to regenerate but that will happen as soon as one single message will reach the archives and the archive.py script will rebuild all the needed files / urls. Thanks for reporting Emanuele! and keep them coming if you spot anything else.
Excellent, thanks! Would be great if some redirect were put in place from those old pages, as Google often still point to them and there may be many other sites doing the same. Even a redirect always pointing to the component main page, eg. https://developer.gnome.org/glib, would be nice though.
The redirects are now in place. Thanks!
(In reply to comment #3) > The redirects are now in place. Thanks! Mh, they don't seem to work properly: https://developer.gnome.org/glib/2.29/glib-GVariant.html → https://developer.gnome.org/glib//glib-GVariant.html
Argh, I forgot that we actually needed to redirect all the pages and not just /glib/{2.29, 2.31, 2.33, 2.35} from there, it should be working now and apache will try to find a match between the page you tried to search on the removed folders and the same page on the latest 2.37 release.
Awesome, thanks!