Hi Steven, I'm in favor of trying to switch runserver to use gunicorn instead of expanding the functionality of our own homegrown webserver (https://code.djangoproject.com/ticket/21978). Windows support still remains an unsolved issue (https://github.com/benoitc/gunicorn/issues/524), but I don't think the lack of Windows support should stall that effort or justify adding SSL support to the homegrown runserver.
Tim On Saturday, May 9, 2015 at 1:22:33 PM UTC-4, Steven Berry wrote: > > From what I understand that's predicated on a *nix environment. So while > it's a perfectly reasonable solution, and one which I may end up using > myself, it doesn't cover all bases. > > I can certainly understand if the goal is to keep runserver as slim as > possible so as not to reproduce functionality found elsewhere. However, I'd > be more comfortable with that demarcation erring on the inclusive side of > rudimentary TLS support, which in today's internet is more or less a > requirement for production development. Obviously runserver shouldn't start > to reproduce more functionality from gunicorn such as UNIX sockets (I'm > sure there's more, but I'm less familiar with it than I'm sure you are). > > I defer to better and more experienced judgement, but as a developer and > end-user those are my thoughts and persistent pain points. > > Regards, > Steven > > > On Saturday, May 9, 2015 at 12:36:50 PM UTC-4, Gert Van Gool wrote: >> >> Hi Steven, >> >> It might be handier to use gunicorn with SSL support[1] and since there >> is already a section in the Django documentation on how to use gunicorn in >> a project[2]. >> >> >> [1]: http://gunicorn-docs.readthedocs.org/en/latest/settings.html#ssl >> [2]: >> https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/gunicorn/ >> >> -- Gert >> >> Twitter: @gvangool <http://twitter.com/gvangool> >> Web: http://gertvangool.be >> >> On Sat, May 9, 2015 at 4:19 PM, Steven Berry <steven....@gmail.com> >> wrote: >> >>> While working with an OAuth library I was running into some issues >>> signing requests on a local development server due to lack of HTTPS. >>> >>> To solve this problem I was deploying web application code to a VM with >>> a shared folder or SCP and running an TLS-enabled nginx server. Obviously >>> the development/test latency here is unacceptable. I looked into what >>> solutions were out there and found a Django plugin django-runsslserver ( >>> https://github.com/teddziuba/django-sslserver). I installed this app, >>> but was disappointed by a few things: >>> >>> >>> - The included certificates didn't work due to an EOF openssl error >>> - I was required to install an additional app (even just doing a += on >>> the INSTALLED_APPS tuple in a separate development settings module >>> felt a bit wonky) >>> - I now had command bifurcation when running development servers -- >>> runserver, runsslserver, and testserver (which in turn didn't >>> support SSL) >>> - The code was necessarily repetitive because Django does not >>> currently abstract the django.core.servers.basehttp module enough >>> for this purpose >>> >>> I felt like this was something Django should just optionally support out >>> of the box for simple use cases such as my own. I forked Django and >>> switched my installed version in my virtual environment to my fork with >>> "pip >>> -e". I used this myself for a while, but I thought my modest change >>> would be objectively useful for others and would be relatively trivial to >>> review and implement. >>> >>> For reference I developed a fix here >>> https://github.com/sjberry/django/commit/c8e808d70f4a0ac6ebf4634576a2538b4f35b83e >>> and >>> subsequently submitted a PR here >>> https://github.com/django/django/pull/4633. Though the PR was >>> admittedly out of order due to my inexperience with the contribution >>> protocol. >>> >>> Let me know if I'm off base here. >>> >>> Regards, >>> Steven Berry >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/40207727-f555-4c1a-bdc4-dcc40e9be935%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/40207727-f555-4c1a-bdc4-dcc40e9be935%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1428d3dc-d36b-4e1e-8b4a-c20b618d5f0a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
