[Web-SIG] Draft 2: WSGI Response Upgrade Bridging

[Benoit Chesneau]

On Tuesday, October 14, 2014, Robert Collins <robertc at robertcollins.net>
wrote:

On 14 October 2014 01:18, Benoit Chesneau <bchesneau at gmail.com> wrote:

>> C - Support for chunked uploads, comet, bosh and websockets is
>> effectively impossible within WSGI - one ends up writing server
>> specific code, and being tied to a single server - even though
>> multiple servers support (some of) those things. This defeats the
>> point of WSGI IMNSHO: its not that WSGI is broken or anything, its
>> just that we're once again writing all our generic middleware in
>> server-specific fashions. Because the world has moved on and we
>> haven't.
>
>
> Chunkedn upload is possible and already handled with Gunicorn. But there
is
> no standard for that.

Right. Thus we need one.

> For C I would separate it from the rest. This a different discussion and
imo
> not everything can be achieved at the same time. Maybe we should start
first
> by fixing them, then go for the next step anyway. So the transition could
be
> incremental in servers and frameworks and actually fix the current spec.

What makes C a different discussion?

>
> For A (And C), i think we should keep the new specification enough
agnostic.
> Especially since HTTP 2 is not yet completely out.

HTTP/2 is in last call stage: it will be entirely finished by the time
we get through whatever process we have here.

What do you want to see changed in the process I'm following?

-Rob


I meant there are 2 separate problems: fixing the current spec, and extend
it **if** needed to handle the new web patterns. I am speaking more about
patterns than protocols. Protocol is one thing to take in consideration of
course, but actually if we redefining a  spec to build (server) and
interact with (apps) a gateway for the web it will be more than simply
handling HTTP 2 and soon HTTP 2.1 or 3 depending on the discussions.

On the server started I started recently a redesign of the core of Gunicorn
to prepare it tfor this pattern and beeing able to handle the different
challengenns they gives. I actually identified some common features and
distinct features.


In term of patterns we have the following:

- start a response: detect the protocol, eventually *upgrade* it to a
new protocol (HTTP -> Websockets or HTTP2 -> HTTP 1.1)
- send/receive headers
- PUSH pattern: HTTP 2,  new  PUSH specifcations from W3C, SSE
- ASYNC pattern: HTTP 2 and Websockets, receiving and sending can happen at
different time and on the long term
- Continuous connections: keepalive, HTTP 2 channels, websockets, SSE  (how
do we keep/identify connections states)
- Streaams: chunked encoding,  http 2 channels, ... We should have a  clear
way to notify the application about it.

Also the spec/the server should have a standard way to handle the different
async frameworks not based on threads like gevent, eventlet.

The application should also be able to tell to the server that an operation
will take a long time and  let the server take appropriate actions. Some
kind of reply/no_reply pattern allowing to answer later and  switch to an
async pattern on the fly if the server support it. It would allows the
servers to handle more gracefully some common issues like long queries when
the application knows about them.

Since there is a concensus on using the github tracker, should i open
a tickets for these different things? Or one generic? Let me know.


- benoit





--
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20141014/f8349413/attachment.html>