On 27 September 2014 07:58, PJ Eby <p...@telecommunity.com> wrote:
> On Thu, Sep 25, 2014 at 11:32 PM, Robert Collins
> <robe...@robertcollins.net> wrote:
>> So I propose we drop the write callable, and include a queue based
>> implementation in the adapter for PEP-3333 code.
>
> If you're dropping write(), then you might as well drop
> start_response() altogether, and replace it with returning a (status,
> headers, body-iterator) tuple, as in wsgi_lite (
> https://github.com/pjeby/wsgi_lite ) or as found in other languages'
> versions of WSGI. (start_response+write was only ever needed in order
> to support legacy apps, so other languages never bothered.)
Ahha! useful history. That would save a load of complexity on server
and middleware authors behalf.
HTTP/2 has moved status to a pseudo header and dropped the status
reason, so we could also phrase this as:
(headers, body-iterator)
Also, (filing an issue now) we also need to support Trailers, which
HTTP/2 has preserved. So we need a final header block facility as
well.
That structure would lead to
(headers, body-iterator, trailers-callback)
But perhaps it would be nicer to say:
iterator of headers_dict_or_body_bytes
With the first item yielded having to be headers (or error thrown),and
the last item yielded may be a dict to emit trailers.
So:
def app(environ):
yield {':status': '200'}
yield b'hello world'
yield {'Foo': 'Bar'}
is an entirely valid, if trivial, app.
What do you think?
> wsgi_lite has a couple of other protocol extensions, namely the
> 'wsgi_lite.closing' environment key, flagging callables' supported
> WSGI version (for transparent interop), and the argument binding
> protocol, but for the most part these are orthogonal to the calling
> schema. I would suggest, however, that the calling protocol be
> flagged in some way to allow easier interop.
We're bumping the WSGI version, will that serve as a sufficient flag?
The closing thing is nice - its basically unittest.TestCase.addCleanup
for WSGI, allowing apps to not have to write a deep nested finally.
Lets start a new thread about the design for that specifically. You
note that exception management isn't defined yet - perhaps we can
tackle that as a group?
-Rob
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
