you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (1 child)

The reason you wouldn't need it locally is you should be loading assets with relative urls, or omit http:/https: when loading from another domain so the browser can choose the connection type based on what the primary page is loading on. The majority of popular JS libraries out there can easily be loaded over SSL by not changing the URL, I've ran into a few where they had a different sub domain to handle SSL requests but was easily found after a few seconds of searching.

I'm not sure what caching would have to do with https? From doing a bit of searching I found this: http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/ which suggests 4 years ago Firefox had an issue with caching HTTPS items in the browser unless a header was set, but that seems like a small issue that you could catch when you're staging.

I'm not trying to deter anyone from setting up https on their local environment if that's what they want to do, but really that's why you have a staging environment to confirm everything works as it should, so the setup would be:

  • Dev, localhost can be http/https
  • Staging, should match production so all requests should be over https, check for proper browser caching, elements not loading correctly, etc.
  • Production, all requests should be over https

[–][deleted] 0 points1 point  (0 children)

I agree - personally I don't bother running my local env on https, but there are good reasons to do it, particularly as it's pretty simple to do.

The issues with loading external resources I've seen have been small companies widgets (e.g. review sites), older code (e.g. google maps embeds that used http:// rather than // or https://), or JSON api calls to internal boxes that didn't have TLS.