Friday, June 27, 2014

Re: [ANNOUNCE] Django 1.7 release candidate 1

On Fri, Jun 27, 2014 at 3:12 AM, cercatrova2 <> wrote:
"FastCGI support via the runfcgi management command will be removed in Django 1.9. Please deploy your project using WSGI."

Why does the documentation *persist* in confusing FastCGI with WSGI?

This does not confuse them (if it were confusing them, it would assume that FastCGI and WSGI are identical).

And it seems that the point made in the developer thread about deprecation being unwise was simply ignored and intentionally misunderstood (!topic/django-developers/oGmD8LvLTPg "Deprecate FCGI support in Django 1.7").

I don't see anyone ignoring or intentionally misunderstanding in that thread.

The "runfcgi" command and its supporting code just implements a FastCGI<->WSGI bridge using flup. That's convenient for cases where FastCGI is the only deployment option, but it does come at a significant cost: flup appears to be abandonware, and the flup-based bridge has generated a lot of bugs and maintenance headaches. That cost was deemed the bigger issue, and so Django will no longer have a built-in FastCGI<->WSGI bridge based on flup.

This doesn't mean that Django can't be deployed using FastCGI, of course; it just means that someone else needs to provide the bridge from FastCGI to WSGI, because going forward Django will only support speaking WSGI, and will not include its own bridge to let it pretend to speak FastCGI or other gateway protocols. And in that thread several people showed interest in starting and maintaining a third-party package to provide that bridge. If FastCGI is a requirement for you, your best course is likely to follow up on that effort.

You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
To post to this group, send email to
Visit this group at
To view this discussion on the web visit
For more options, visit

No comments:

Post a Comment