Re: [Django] #12091: [PATCH] Support for WSGI applications within Django
Django
---------------------------------------+-------------------------------
Reporter: Gustavo | Owner: Gustavo
Type: New feature | Status: new
Milestone: | Component: HTTP handling
Version: SVN | Severity: Normal
Resolution: | Keywords: WSGI
Triage Stage: Accepted | Has patch: 1
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 1 | Easy pickings: 0
---------------------------------------+-------------------------------
Changes (by patchhammer):
* needs_better_patch: 0 => 1
* easy: => 0
Comment:
wsgi-apps.diff fails to apply cleanly on to trunk
--
Ticket URL: <http://code.djangoproject.com/ticket/12091#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Gustavo | Owner: Gustavo
Type: New feature | Status: closed
Component: HTTP handling | Version: master
Severity: Normal | Resolution: wontfix
Keywords: WSGI | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
-------------------------------+------------------------------------
Changes (by aaugustin):
* status: new => closed
* resolution: => wontfix
Comment:
I'm in favor of keeping this feature outside of Django, for the following
reasons.
1) Embedding WSGI applications in Django isn't the most robust design.
It's much better to dispatch at the WSGI level between Django and other
applications.
2) While it's easy to just make this feature work for simple use cases,
it's very difficult to make the gateway 100% WSGI-compliant (even if the
recently-added `StreamingHttpResponse` could help abide by the buffering
rules). I'm afraid this would add a significant maintainance load, while
benefitting only a few users with non-trivial architectures.
3) There isn't any reason why this needs to live in core, and there are a
few implementations floating in the wild. I have my own implementation of
this too -- I use it in development as a replacement for
`uwsgi.applications`
(http://projects.unbit.it/uwsgi/wiki/ApplicationsDict).
--
Ticket URL: <https://code.djangoproject.com/ticket/12091#comment:10>
Django
-------------------------------+------------------------------------
Reporter: Gustavo | Owner: Gustavo
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
* status: closed => new
* resolution: wontfix =>
Comment:
1) "Dispatch at the WSGI level" is ambiguous. I assume you mean dispatch
before Django is reached, which wouldn't be better or even accomplish the
same. Picture this example: You want to use the [https://launchpad.net
/wsgi-xsendfile WSGI X-Sendfile] application from a Django view because
you want to (1) check that the user can download the file, (2) log who's
downloading the file and (3) log when the file was downloaded. Try to do
that outside of Django and you'll end up with an unmaintainable piece of
code.
2) I'm not sure I understand this point well enough. What does the gateway
have to do with all this? Anyway, I can assure you that this is a piece of
cake and it's 100% reliable in 100% of the cases you can imagine. I've
reimplemented a variant of that patch in
[http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html twod.wsgi]
and presented demos of how you can proxy applications like
[https://bitbucket.org/Gustavo/weesgo/ Trac] and
[http://gustavonarea.net/files/talks/europython2010/all-materials.zip the
PHP-powered Wordpress] via Django. What complicated situations can you
imagine that wouldn't be supported?
3) I think you're confusing "embedding WSGI applications inside Django"
with "routing WSGI applications". Both can be quite useful, depending on
your needs, but there's a big difference. This ticket is about embedding,
but you're talking about routing.
I also want to add that all the other mainstream WSGI framework have
supported this outside-the-box for years.
I'll dare reopening this ticket because I think there's been a
misunderstanding, and would like to prevent this ticket from going
unnoticed for years again.
--
Ticket URL: <https://code.djangoproject.com/ticket/12091#comment:11>
Django
-------------------------------+------------------------------------
Reporter: Gustavo | Owner: Gustavo
Type: New feature | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: WSGI | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by aaugustin):
Replying to [comment:11 Gustavo]:
> 1) "Dispatch at the WSGI level" is ambiguous. I assume you mean dispatch
before Django is reached, which wouldn't be better or even accomplish the
same. Picture this example: You want to use the [https://launchpad.net
/wsgi-xsendfile WSGI X-Sendfile] application from a Django view because
you want to (1) check that the user can download the file, (2) log who's
downloading the file and (3) log when the file was downloaded. Try to do
that outside of Django and you'll end up with an unmaintainable piece of
code.
For such cases, I suggest to use an external Django view to WSGI mapper —
twod.wsgi or one of the many other packages providing the same feature.
> 2) I'm not sure I understand this point well enough. What does the
gateway have to do with all this? Anyway, I can assure you that this is a
piece of cake and it's 100% reliable in 100% of the cases you can imagine.
I've reimplemented a variant of that patch in
[http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html twod.wsgi]
and presented demos of how you can proxy applications like
[https://bitbucket.org/Gustavo/weesgo/ Trac] and
[http://gustavonarea.net/files/talks/europython2010/all-materials.zip the
PHP-powered Wordpress] via Django. What complicated situations can you
imagine that wouldn't be supported?
Django is a WSGI application. If it acts as a WSGI server too, that makes
it a WSGI gateway. As such, it'll be expected to honor the spec for WSGI
gateways. People can be unbelievably annoying with spec-compliance bugs.
Let's take this sentence from PEP 3333:
> WSGI servers, gateways, and middleware must not delay the transmission
of any block; they must either fully transmit the block to the client, or
guarantee that they will continue transmission even while the application
is producing its next block.
twod.wsgi doesn't respect this when the write() callable is used. (To you
credit, you handled the iterator case correctly.)
Describing something as a piece of cake and 100% correct isn't good for
your credibility when I can find a bug through code inspection!
> 3) I think you're confusing "embedding WSGI applications inside Django"
with "routing WSGI applications". Both can be quite useful, depending on
your needs, but there's a big difference. This ticket is about embedding,
but you're talking about routing.
Well, the very first example in twod.wgsi's docs is called embedding but
it actually shows routing:
http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html#embedding-non-
django-applications
The second example is about embedding:
http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html#calling-them-
from-a-django-view
The concepts aren't as neatly delimited as you make it sound, and both can
be implemented as external apps.
> I also want to add that all the other mainstream WSGI framework have
supported this outside-the-box for years.
Django isn't a "WSGI framework" per se — it uses WSGI as a deployment
platform, that's all. Besides, this isn't a competition.
> I'll dare reopening this ticket because I think there's been a
misunderstanding, and would like to prevent this ticket from going
unnoticed for years again.
Sure, we can leave it open for now, I'll let someone else make the
decision.
--
Ticket URL: <https://code.djangoproject.com/ticket/12091#comment:12>
Django
-------------------------------+------------------------------------
Reporter: Gustavo | Owner: Gustavo
Type: New feature | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: WSGI | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by Gustavo):
Replying to [comment:12 aaugustin]:
> Replying to [comment:11 Gustavo]:
> > 1) "Dispatch at the WSGI level" is ambiguous. I assume you mean
dispatch before Django is reached, which wouldn't be better or even
accomplish the same. Picture this example: You want to use the
[https://launchpad.net/wsgi-xsendfile WSGI X-Sendfile] application from a
Django view because you want to (1) check that the user can download the
file, (2) log who's downloading the file and (3) log when the file was
downloaded. Try to do that outside of Django and you'll end up with an
unmaintainable piece of code.
>
> For such cases, I suggest to use an external Django view to WSGI mapper
— twod.wsgi or one of the many other packages providing the same feature.
Then why not provide it in Django and prevent the proliferation of
implementations to accomplish this? That's indicative that there's a
demand for this.
> > 2) I'm not sure I understand this point well enough. What does the
gateway have to do with all this? Anyway, I can assure you that this is a
piece of cake and it's 100% reliable in 100% of the cases you can imagine.
I've reimplemented a variant of that patch in
[http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html twod.wsgi]
and presented demos of how you can proxy applications like
[https://bitbucket.org/Gustavo/weesgo/ Trac] and
[http://gustavonarea.net/files/talks/europython2010/all-materials.zip the
PHP-powered Wordpress] via Django. What complicated situations can you
imagine that wouldn't be supported?
>
> Django is a WSGI application. If it acts as a WSGI server too, that
makes it a WSGI gateway. As such, it'll be expected to honor the spec for
WSGI gateways. People can be unbelievably annoying with spec-compliance
bugs.
I see. Agreed.
> Let's take this sentence from PEP 3333:
>
> > WSGI servers, gateways, and middleware must not delay the transmission
of any block; they must either fully transmit the block to the client, or
guarantee that they will continue transmission even while the application
is producing its next block.
>
> twod.wsgi doesn't respect this when the write() callable is used. (To
you credit, you handled the iterator case correctly.)
Actually, the write() callable is supported just fine. twod.wsgi doesn't
do anything with it because it delegates it to WebOb's
Request.call_application(), which supports write() the way it's supposed
to: https://github.com/Pylons/webob/blob/master/webob/request.py#L1238
> Describing something as a piece of cake and 100% correct isn't good for
your credibility when I can find a bug through code inspection!
The approach '''is''' a piece of cake, even if there are bugs in my
implementation, which may well be the case because I'm a human! "100%
correct" are your own words, isn't that right? I said "100% reliable in
100% of the cases you can imagine", and I stand by it.
And what you've found isn't a bug, unless I've misinterpreted your reply.
> > 3) I think you're confusing "embedding WSGI applications inside
Django" with "routing WSGI applications". Both can be quite useful,
depending on your needs, but there's a big difference. This ticket is
about embedding, but you're talking about routing.
>
> Well, the very first example in twod.wgsi's docs is called embedding but
it actually shows routing:
> http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html#embedding-
non-django-applications
> The second example is about embedding:
> http://pythonhosted.org/twod.wsgi/manual/embedded-apps.html#calling-
them-from-a-django-view
No, it's embedding. make_wsgi_app() returns a Django view, which makes a
huge difference.
Consider this example: If the embedded WSGI app relies on REMOTE_USER for
authentication and Django previously authenticated the current user, then
the embedded app will reuse Django's authentication. By contrast, if you
route requests to the same WSGI app outside of Django, as you suggest, the
embedded WSGI app won't be able to reuse Django's authentication.
> The concepts aren't as neatly delimited as you make it sound,
Well, they are and they've been for ages with other Python frameworks.
> and both can be implemented as external apps.
No.
> > I also want to add that all the other mainstream WSGI framework have
supported this outside-the-box for years.
>
> Django isn't a "WSGI framework" per se — it uses WSGI as a deployment
platform, that's all. Besides, this isn't a competition.
I didn't mean that as a call for competition or anything. I just wanted to
point out that everywhere else this functionality is taken for granted and
yet here we are discussing whether it should be part of Django itself,
while other Django users continue creating their own implementations for
the missing functionality.
It may not be its primary focus, but Django is a WSGI framework, just like
TurboGears, Pylons, etc. [http://gustavonarea.net/files/talks/twodwsgi-
djugl.pdf WSGI is more just a deployment platform].
> > I'll dare reopening this ticket because I think there's been a
misunderstanding, and would like to prevent this ticket from going
unnoticed for years again.
>
> Sure, we can leave it open for now, I'll let someone else make the
decision.
Thanks! I wonder whether this should be taken to the mailing list.
--
Ticket URL: <https://code.djangoproject.com/ticket/12091#comment:13>
Django
-------------------------------+------------------------------------
Reporter: Gustavo | Owner: Gustavo
Type: New feature | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: WSGI | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
Comment (by aaugustin):
Discussion on django-developers: https://groups.google.com/d/msg/django-
developers/137ZyyBNq5c/C6v7LUdZYNUJ
--
Ticket URL: <https://code.djangoproject.com/ticket/12091#comment:14>
Django
-------------------------------+------------------------------------
Reporter: Gustavo | Owner: Gustavo
Type: New feature | Status: new
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: WSGI | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
--
Ticket URL: <https://code.djangoproject.com/ticket/12091#comment:15>