Pull request https://github.com/django/django/pull/4633/ withdrawn.
Closing comments attached to the issue describing my interim (and likely
permanent) fix to all of my Django sites after taking Gert's suggestion.
I'll likely create a few blog posts detailing deployment processes instead
of pes
Florian,
I was merely presenting a rhetorical question to illustrate a point.
Perhaps there weren't other available web servers then, but there are now,
as has been pointed out. Prevalence and expectation of TLS/SSL is another
thing that's changed since 2005. We can choose to maintain runserver
Hi,
On Tuesday, May 12, 2015 at 4:43:41 AM UTC+2, Steven Berry wrote:
>
> 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
On Mon, May 11, 2015 at 4:34 PM, Tim Graham wrote:
> 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
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 *wel
Hi Russ,
On 05/11/2015 06:05 PM, Russell Keith-Magee wrote:
>
> I'm completely on-board with the idea of switching to a "real" web
> server rather than continuously improving our own.
>
> However, there might be better options than gunicorn. Graham Dumpleton
> has released mod_wsgi-express:
>
I'm completely on-board with the idea of switching to a "real" web server
rather than continuously improving our own.
However, there might be better options than gunicorn. Graham Dumpleton has
released mod_wsgi-express:
http://blog.dscpl.com.au/2015/04/introducing-modwsgi-express.html
which is a
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"
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 t
Tim,
Thanks for taking the time to respond to this and sending those links. I
familiarized myself with the gunicorn issues list when Gert suggested using
it, but I was unaware of #21978.
As the ticket suggests I don't think it's the current goal to deprecate the
runserver command entirely (cor
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
>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 functionali
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/deplo
13 matches
Mail list logo
