-
Notifications
You must be signed in to change notification settings - Fork 264
Support https for badge #134
Comments
It looks like the |
There is the future possibility of shields.io hosting the badge image and taking care of HTTPS. badges/shields#66 Sheilds.io would contact GoDoc.org to determine the badge status. If that API doesn't require SSL, then godoc wouldn't need the certificate. |
HTTPS was added back in as of Dec 20. Note: It's not absolutely necessary to have the link be HTTPS such that people navigate around the site in SSL. Just the image src needs to be HTTPS for cache busting. |
Thanks for the SSL check links. It does look like it could be setup a bit better. Yet I'm not seeing an issue in Firefox 26 (OS X) with my badge on Looper. Can you give more specifics, such as:
|
Thanks for taking the time to check. I have attached screenshots with the $ curl 'https://godoc.org/github.com/gophertown/looper?status.png' On Sat, Jan 4, 2014 at 11:54 AM, Nathan Youngman
|
@speter Thanks for following up. Of note, HTTPS is only necessary to break GitHub's caching of the status badge. However, the status badge image is completely static right now (it always says "Reference" in green), so HTTP works perfectly fine. As far as fixing the certificate chain, that's something I don't have the knowledge or access to do, so I'll have to leave to @garyburd when he finds some time. Longterm we may use shields.io as a secure badge server for GoDoc, see badges/shields#81. Just getting started on that project now. |
@garyburd Thanks for the prompt fix! FWIW it seems that it is better to include intermediate certificates for reduced load time even if it doesn't cause an error. https://www.wormly.com/help/ssl-tests/intermediate-cert-chain (bottom part "But my browser accepts the certificate!") Perhaps Firefox not fetching it from a remote site is meant to discourage the bad practice of not including it. @nathany My primary concern was not the cache issue, or that the image is currently static, but the first one mentioned in the initial description: "The badge cannot be used on an https page without triggering the browser's insecure content warning." (This affects all browsers, not just Firefox, when the badge is referenced via http from an https site other than github.) From my point of view, this specific aspect is resolved for now. |
Another reason to be glad we're using HTTPS: badges/buckler#27 |
The badge cannot be used on an https page without triggering the browser's insecure content warning.
There's no warning on GitHub pages because GitHub proxies and caches the badge. This is a problem if we ever want to change the badge on fly.
The text was updated successfully, but these errors were encountered: