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.

Reply via email to