Hi Rodric,
"...without running the full test suite against both HTTP and HTTPS deployments, I for one can't say what will and will not work...." I assume you're referring to the test suite for the CLI, right ? So the argument is that we can simplify the CLI tests by removing NGINX from the local env, assuming that w/o NGINX we can invoke the endpoints in the controller via HTTP b/c NGINX should only listen on port 443 ? Thanks, dragos ________________________________ From: Rodric Rabbah <rod...@gmail.com> Sent: Sunday, July 23, 2017 7:28:17 AM To: dev@openwhisk.apache.org Subject: http enablement in nginx for local development If you've deployed openwhisk locally you'll have noticed that the nginx is listening on port 443 only (https); for local development, we document a workaround to the self-signed SSL certificate by bypassing nginx. This is helpful for switching deployments from local to production where the latter will have a valid certificate but the former requires some additional flags for wsk CLI or curl to ignore the certificate. A while ago PR 2042 was offered to open port 80 [1] and enables HTTP as a convenience for local dev since it avoids having to ignore the self-signed cert. On the other hand, this path is not tested explicitly and could rot but more so, without running the full test suite against both HTTP and HTTPS deployments, I for one can't say what will and will not work. At one point, we explored storing the insecure flag in the wsk CLI properties file but ended up abandoning (see PR 1838 [2]) and instead documenting a convenient but limited workaround instead (bypassing nginx). [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F2042&data=02%7C01%7C%7C1e26f14d4bb84aee3c8108d4d1d72f8e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636364169522575347&sdata=3MZ%2FyfPbAZJ%2FqnRz8pLyVQ0MF9NahgGrZk71UNNIAMI%3D&reserved=0 [2] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-openwhisk%2Fpull%2F1838&data=02%7C01%7C%7C1e26f14d4bb84aee3c8108d4d1d72f8e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636364169522575347&sdata=VJniIpCYlvsB1743CCGMehJ6XHDZlhAmpEVDH2Ug%2F5c%3D&reserved=0 I'm inclined to continue to only support HTTPS and in fact push this protocol even further inside the deployment. Thoughts? I will summarize the dev list discussion on the PR as appropriate and then we can decide that to do with the offered patch. -r