After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 761673 - website not SSL-enabled
website not SSL-enabled
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: www
1.6.1
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-02-07 16:47 UTC by Daniel Stone
Modified: 2016-02-18 16:13 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Daniel Stone 2016-02-07 16:47:35 UTC
I've been enabling SSL across the fd.o websites, and I've not been able to properly enable it for GStreamer as the site contains a huge number of hardcoded non-SSL references:

root@annarchy:/srv/gstreamer.freedesktop.org/www/htdocs% grep http://gstreamer.freedesktop.org/ index.html | wc -l
69

For example, this includes the CSS which triggers mixed-content warnings.

If these links were converted to either relative or just SSL-only, we could switch the site over.
Comment 1 Tim-Philipp Müller 2016-02-07 18:59:02 UTC
The way things are set up, it's a bit awkward to convert things to relative URIs.

I can easily change everything to https:// though.

Can we also make it redirect http:// -> https:// somehow? (via .htaccess or whatnot)
Comment 2 Tim-Philipp Müller 2016-02-07 19:00:08 UTC
PS: thanks for working on this!
Comment 3 Daniel Stone 2016-02-07 19:13:15 UTC
At the moment they're both serving the same site, so if you push a change to make them all https, I'll turn the (currently-disabled) redirect back on and that should be a smooth transition.
Comment 4 Sebastian Dröge (slomo) 2016-02-16 15:54:10 UTC
Why is it awkward to fix for both though? Couldn't we just use relative URLs everywhere?
Comment 5 Tim-Philipp Müller 2016-02-16 16:00:47 UTC
Because we use &site;/foo/bar basically everywhere, which will be replaced with the site address.

I don't see anyone converting all of those to relative URIs though. I'm also not sure it's desirable in all cases.
Comment 6 Daniel Stone 2016-02-16 16:04:28 UTC
Can &site; not just expand to nothing?

Having both HTTP and HTTPS sites means that we have to maintain (and test) two separate configs - more work whenever we need to change anything, and one more thing to go wrong.
Comment 7 Daniel Stone 2016-02-18 14:42:29 UTC
Also, our preference is for HTTPS-only sites; changing the 'site' expansion to the HTTPS variant will work (as plain-HTTP will load HTTPS resources) without breaking the reverse (HTTPS site will never load plain-HTTP resources). So if you just push that change then we should be safe for the transition.
Comment 8 Jan Schmidt 2016-02-18 15:53:05 UTC
(In reply to Daniel Stone from comment #6)
> Can &site; not just expand to nothing?
> 
> Having both HTTP and HTTPS sites means that we have to maintain (and test)
> two separate configs - more work whenever we need to change anything, and
> one more thing to go wrong.

I don't think there's any problem with just making &site; = "". Everything should just convert to absolute paths without a hostname and work fine, right?
Comment 9 Jan Schmidt 2016-02-18 16:10:18 UTC
Done. Seems to work fine :)

commit 0cbafe8d73f3f8d5ed628c22422086746b87072e
Author: Jan Schmidt <jan@centricular.com>
Date:   Fri Feb 19 03:04:46 2016 +1100

    Make the site entity = "" on the live site.
    
    That makes all links simply be absolute paths on the server.
    Keep using the &site; entity for local builds, so a top-level
    path can be prepended.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=761673
Comment 10 Daniel Stone 2016-02-18 16:13:04 UTC
Yep, and now enabled for pure HTTPS. Thanks Jan!