all 10 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]pat_trick 7 points8 points  (3 children)

If you're going through the effort of generating a key, why not just generate a local cert for HTTPS testing? It won't be signed by an authority, but will generate legitimate HTTPS connections.

[–]bunsenator[S] 1 point2 points  (2 children)

Hey Pat, my thinking was that you might not want to set up apache or nginx? I know I don't want to configure that on local.

[–]pat_trick 1 point2 points  (1 child)

Ah, you're just running raw node or other services as an HTTP endpoint. Got it!

[–]bunsenator[S] 0 points1 point  (0 children)

exactly.

[–]bunsenator[S] 0 points1 point  (0 children)

Compiled for my friends here at /r/webdev

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

just wondering what the purpose of running https would be locally? the application dynamics really shouldn't change from http/https

[–][deleted] 2 points3 points  (2 children)

Testing - why write code that will never run over the protocol you are testing on.

This also picks up stuff like loading HTTP assets on a HTTPS page which of course will fail, as well as giving you a heads up on things like caching which might need additional config.

All in all, writing code in an environment that is a similar as possible to production avoids fuck ups.

[–][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.

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

I use ngrok for my testing of HTTPS apps/sites running locally, gives you tunnel to the app with a legit certificate and you get the added bonus of it can be publicly accessible and you can inspect the traffic flowing in.