All, Thanks for the feedback and input here. I appreciate the experience you guys bring to the table.
On Monday, May 11, 2015 at 6:34:51 PM UTC-4, Alex_Gaynor wrote: > > I don't have a strongly held opinion on whether Django should include > this, but if it's going to, it should include a *well configured* TLS > server, utilizing modern TLS cipher suites, TLS versions, etc. We shouldn't > be yet another part of the "well, it's not *my* job to configure OpenSSL > correctly" problem. > Alex, I think this touches on what Tim and Florian are fearful of. It isn't and shouldn't be Django's responsibility to configure OpenSSL correctly considering that runserver is explicitly recommended against in production. But on that note you bring up a good point, who am I to determine what the minimum runserver TLS support should be? Is it good enough to have simple TLS? Is it essential for developers to be able to specify the TLS version and ciphers? On Monday, May 11, 2015 at 6:30:39 PM UTC-4, Florian Apolloner wrote: > > > On Monday, May 11, 2015 at 10:13:03 PM UTC+2, Steven Berry wrote: >> >> With all that said I'm in favor of what you suggest -- rely on gunicorn >> where possible. However I don't think what I'm suggesting (and have already >> implemented) fundamentally interferes with #21978. As far as I can tell the >> django.core.servers.basehttp module exists solely for the runserver command. >> And the contents therein aren't so much of a homegrown webserver as they >> are convenient subclasses to Python's inherent wsgiref.simple_server. >> The onus of maintenance lies largely in the Python codebase. >> > > It might not interfere, but there are already perfectly fine alternatives > like stunnel which provide you with TLS support. So unless there is a > really compelling argument to TLS support to runserver itself (which I yet > fail to see in this thread), I am -0 to -1. Keeping the code as simple as > possible also makes migrations to a 3rd party server easier later on. > Florian, by that logic what's the point of having runserver in the first place? There are already perfectly fine alternatives that serve web content. What I was suggesting was moving something that is half-baked to something that's at least 60% baked while still taking advantage of what runserver does well. The trick, which I touched on in my second post, and which I think Tim addressed, is identifying what your intended scope is here. If the goal is to deprecate runserver entirely then I agree with you. But that intention hasn't been made clear, and what we're left with is a crippled webserver with a bit of an identity crisis. Based on your feedback I'm convinced that deprecating runserver altogether is probably the best course of action (eventually). However, before that could even be considered I think the documentation would have to be prepared accordingly. I would suggest updating: - https://docs.djangoproject.com/en/dev/howto/deployment/ to remove references to runserver. Perhaps the guide should also be retitled "Serving Django" which would be relevant to both production deployment and local development testing. - Recommend running check instead of runserver. - https://docs.djangoproject.com/en/dev/howto/static-files/ to remove references to runserver. - Add support to the Django settings to automatically (and optionally) add static file URLs based on DEBUG = True and maybe another (new) setting SERVE_STATIC = True. I think this is the only feature I miss from the built-in runserver in switching to third-party servers. For reference there are currently workarounds like this http://stackoverflow.com/a/12801140, but integrating something like that under the hood may help ease the migration path. This would make https://code.djangoproject.com/ticket/21978 as well as my current PR https://github.com/django/django/pull/4633 effectively moot. In the interim I'm just going to pretend runserver doesn't exist and move on with my life (which is what I expect what most of you guys do anyway). Best, Steven -- 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/9b1a89b5-8759-4ce7-ae85-8549b2d3faba%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.