--
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.
For more options, visit https://groups.google.com/d/optout.
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.
--
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/d4e1a606-3af4-43d2-90e4-bed9bcf28ebb%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1428d3dc-d36b-4e1e-8b4a-c20b618d5f0a%40googlegroups.com.
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.
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.
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.