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

[PJ Eby]

On Tue, Sep 30, 2014 at 5:03 AM, Sylvain Hellegouarch <sh at defuze.org> wrote:
> Hi,
>
> 2014-09-30 1:19 GMT+02:00 PJ Eby <pje at telecommunity.com>:
>> * 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.

Right: for the most part, it's an all-or-nothing choice, at least for
a given mount point within the server.  Either it's a WSGI app or a
native app.  The point of the escape is that you can still use your
WSGI framework, with all its routing, session handling,
authentication, application object loading, etc., right up to the
point where you need to do something advanced.  The mensa protocol
allows you to jump out of WSGI and back to the native API at that
point.


> Shouldn't we drop the middleware idea altogether?

For the PEP's purposes, the definition of "middleware" includes web
frameworks themselves.  That is, it allows you to use a framework's
features in tandem with native server APIs, without actually touching
WSGI directly in application code.


> 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.

And the idea of this proposal is that as long as a framework exposes a
*single* `use_native_api()` feature in some way (or exposes enough
WSGI for a user to use the trick shown in the PEP), then the user can
continue to ignore WSGI, but can *also* access low-level, non-WSGI
APIs, to do things that are fundamentally incompatible with WSGI.

(Also, as the PEP mentions, the escape protocol only requires that the
framework allow access to the environ, and provide a way to set the
status, headers, and content of the framework's eventual response.
Any non-trivial framework provides *some* form of these latter three
functions; it's only a question of whether the environ (or a copy of
it) is available to get hold of the `wsgi.native_api_hooks`.)