Can we make the site fully https? This seems to be the only http element left? http://bit-tech.net/static/public/image/body-20160101.jpg Thanks
May wanna check the articles as well. For example, the review of "They are Billions", the screenshots are hard-coded http. Also, the link to twitter points to http.
where we point to isn't that big of an issue but the fact those images are hardcoded is. I'm not sure how as all articles are made the same way but not all images are hard coded. I'll change the link and look into the images now. Thanks
Figured it out. It was a very interesting issue related to how the editors were visiting the site. All new articles should now link you to HTTP images on HTTP connections and HTTPS versions when visiting the site on HTTPS. Thanks again for letting us know. Just realised I forgot to change the twitter link so will do that at some point aswell.
if you want to increase your SEO and decrease server load take a look at cache-control headers as well (how long an image is cached by the client to stop redownloading it )
I'm starting to suspect you're a developer . The article images are already cached by my browser. Just checked in chrome and the images seem to have them unless I'm missing something.
Why not just redirect all http requests to https? If the site's fully secure (it seems to be now) then there's really no need for http anymore. You'd benefit from offering HTTP2 as well. If you go exclusively HTTPS (and you should ), If you set up a content-security-policy header, you can not only specify a policy for browsers to adhere by, but also receive automated reports (via the handy report-uri: directive) which will alert you every time you're serving an asset that violates a policy of your choosing. In other words: rather than people like us starting threads to tell you that, oops, you've missed an insecure image in the site somewhere, you can be alerted to it automatically, which is always nice. Highly recommended, and little known, it seems, at this point in time anyway. Also, there seems to be some disparity between response headers on various assets. This: http://bit-tech.net/static/public/image/body-20160101.jpg only sends back E-Tag and Last-modified headers. ($ curl -I http://bit-tech.net/static/public/image/body-20160101.jpg) However this: https://www.bit-tech.net/media/image/2018/2/a431c5fc-6d33-43ad-9eb7-673e86f3bb1d.jpeg sends back E-Tag and Last-modified, as well as Cache-control and Expires headers (which is good). It seems a bit of consolidation work is required between the two to get responses consistent. And for what it's worth, I'd say the 7 day cache-control+expires headers are a bit conservative; I doubt those assets ever change, so why not cache 'em for much longer?
Doing this on the forums is tricky because a ton of content is from 3rd party hosts and they were posted as HTTP and it's not as simple as just swapping HTTP for HTTPS as: a) I don't think we could do that and b) some sites don't work at all on HTTPS so the images won't show For the main site I'm not sure and as I'm only an apprentice (It was actually a year last week since I joined) I don't really get much say. On the response headers I'm not really sure as I'm pretty sure the way that was implemented was before I got here but it's something I can enquire about. Thanks for all the help. I know it may seem like I don't know a lot but I've only been a dev professionally for a year so I've still got tons to learn and threads like this help me a lot . If you have any resources on this sort of stuff it would be greatly appreciated. My goal here from the start has always been to interact with the community more than in the past to help improve the site so I see all of this as a win.
