[Web-SIG] Pre-PEP: The WSGI Middleware Escape for Native Server APIs

[Sylvain Hellegouarch]

Hi,

2014-09-30 1:19 GMT+02:00 PJ Eby <pje at telecommunity.com>:

> Per the previous discussion about HTTP/2, websockets, et al, here's my
> attempt at providing something we can start using and implementing
> today, as a bridge to future specifications.  If you'd prefer to read
> it nicely formatted, you can find an HTML version in progress at:
>
>     https://gist.github.com/pjeby/62e3892cd75257518eb0
>
> I'm very interested in feedback from server and framework developers
> with relevant experience to help close the "open issues and questions"
> section.  Questions about the content or feedback on its presentation
> would also be very helpful.
>
> (For now, the text is in markdown, but of course I will switch it to
> ReST once it begins stabilizing.)
>
>
> # The WSGI Middleware Escape for Native Server APIs
>
> # Overview
>
> This document specifies a proposed standard WSGI extension that allows
> WSGI applications to "escape" the standard WSGI API and access native
> web server APIs, such as websockets, HTTP/2 features, or
> Twisted/tulip-style asynchronous APIs.
>
> The proposed extension, the Middleware Escape for Nativer Server APIs
> or "MENSA", allows WSGI to continue to be used for the 98% of typical
> web application use cases that fall within the basic HTTP/1.0
> "request/response" paradigm, while allowing the 2% of use cases with
> more sophisticated requirements to still benefit from "inbound" WSGI
> middleware for sessions, authentication, authorization, routing, and
> so forth, as well as keeping the other advantages of sharing the same
> process with other WSGI code.
>
> Specifically, the MENSA protocol allows a WSGI application to
> *dynamically* switch at runtime from using a standard WSGI response,
> to using a web server's "native" API to handle the current request
> (and possibly subsequent ones), subject to certain conditions.
>
> This approach provides present-day WSGI applications and frameworks
> with a smooth upward migration path in the event that they require
> access to websockets, HTTP/2-specific features, etc.  With it:
>
> * Web servers can expose their native API to any WSGI application or
> framework
>


It's kind of already the case with all the existing servers. They all
perform the stream reading and HTTP parsing in their own native way and
then adapt those to WSGI.
Basically, all existing Python HTTP servers do this already. For some
servers, you can even bypass the WSGI mapping altogether if you know you're
only stay in the framework native-land.





>
> * Application developers can use existing middleware, libraries, or
> frameworks to handle front-end tasks like routing and authentication
>
>
Shouldn't we drop the middleware idea altogether?

Maybe I'm being bold but when I look at some popular frameworks, many seem
to escape WSGI itself already.
They take a WSGI context and transform it to their native context. Then
back again from their native response to the WSGI context (with a
performance penalty in the process):

* Django
https://github.com/django/django/blob/master/django/core/handlers/wsgi.py#L83
* CherryPy
https://bitbucket.org/cherrypy/cherrypy/src/4939ea9fbe6b0def376fbb349c039c38b0a8994b/cherrypy/_cpwsgi.py?at=default#cl-223
* web2py https://github.com/web2py/web2py/blob/master/gluon/globals.py#L154

Others stick closer to WSGI all the way but still hide it more or less:

* Flask/Werkzeug provide properties above the environ dictionary itself
https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/wrappers.py
* Bottle has its own wrapper as well:
https://github.com/defnull/bottle/blob/master/bottle.py#L995
* Pyramid is based on WebOb

Servers seem happy enough to expose HTTP through WSGI for convenience and
compatibility but, frameworks use native objects and workflow and forget
about WSGI altogether. I seldom see them expose the environ or
start_response at a high level. Those details are kept hidden to respect
(sometimes brokenly) the WSGI protocol.

-- 
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20140930/ec87ae43/attachment.html>