On 13 September 2014 19:40, Robert Collins wrote:
> Is anyone interested in collaborating on an update to WSGI to support
> HTTP/2's new features?
I'd be happy to help. I know extremely little about WSGI (though I'm
sure I can read up on it), but I'm pretty heavily involved with HTTP/2
(as you kn
On 20 September 2014 08:23, Robert Collins wrote:
> I will happily discuss stuff with you off-list, but I'm not
> particularly interested in having the primary effort be cabal style -
> HTTP/2 has managed to go through a much harder rev with very strong
> personalities and much the same sort of de
On 20 September 2014 15:17, Benoit Chesneau wrote:
> 1) HTTP 1.1 vs HTTP 2:
>
> - HTTP 1.1 and HTTP2 have quite the same high level syntax (methods, uri,
> headers, ...) but the way the data is transported differs. (data are sent by
> frames in HTTP 2).
Yes, this is correct. *In principle*, much
On 30 September 2014 08:41, Roberto De Ioris wrote:
> While i totally like your proposal, i fear it will not solve one of the
> biggest problems without another layer:
>
> currently (and i speak as the uWSGI author, so i am the first guilty here)
> when you want to use non-WSGI features you genera
All,
**TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do it
at all?**
It’s a new year, and that means it’s time for another attempt to get WSGI 2.0
off the ground. Many of you may remember that we attempted to do this last year
with Rob Collins leading the charge, but
> On 4 Jan 2016, at 12:27, Cory Benfield wrote:
>
> All,
>
> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do
> it at all?**
Having set up the conversation, I also want to take part in it. So let me
outline what I think we need from WSGI 2.
In
> On 4 Jan 2016, at 14:48, Damjan Georgievski wrote:
>
>> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do
>> it at all?**
> …
>> - Support websockets
>> - Support HTTP/2
>
> What does HTTP/2 support mean? What features of HTTP/2 need to be
> exposed in the wsgi api
> On 4 Jan 2016, at 14:56, Damjan Georgievski wrote:
>
**TL;DR: What do you believe WSGI 2.0 should and should not do? Should we
do it at all?**
>>> …
- Support websockets
- Support HTTP/2
>>>
>>> What does HTTP/2 support mean? What features of HTTP/2 need to be
>>> exposed
> On 4 Jan 2016, at 15:08, Armin Ronacher wrote:
>
> I honestly do not think that you can have it both ways: a WSGI specification
> and a raw socket. Maybe we reached the point where WSGI should just be
> deprecated and frameworks themselves will fill the gap. We would only specify
> a data
> On 5 Jan 2016, at 00:12, Graham Dumpleton wrote:
>
>
>> On 4 Jan 2016, at 11:27 PM, Cory Benfield > <mailto:c...@lukasa.co.uk>> wrote:
>>
>> All,
>>
>> **TL;DR: What do you believe WSGI 2.0 should and should not do? Should we do
>>
Forwarding this message from the django-developers list.
Hi Cory,
I’m not subscribed to web-sig but I read the discussion there. Feel free to
forward my answer to the group if you think it’s useful.
I have roughly the same convictions as Graham Dumpleton. If you want to support
HTTP/2 and WebS
> On 6 Jan 2016, at 09:48, Graham Dumpleton wrote:
>
> If this does solve the push issue, what is there in HTTP/2 then that one
> couldn’t do via the existing WSGI interface?
Well, plenty, but none that we’d *want* to expose via WSGI with the possible
exception of long-running bi-directional
> On 6 Jan 2016, at 09:19, Aymeric Augustin
> wrote:
>
> Hello Benoît,
>
> Thanks for clarifying that you also had the reverse problem in mind, headers
> sent by applications. This side is less problematic in the sense that
> application authors can adapt to stronger requirements.
>
> In ge
> On 6 Jan 2016, at 20:06, Graham Dumpleton wrote:
>
>
>> On 6 Jan 2016, at 10:19 PM, Cory Benfield wrote:
>>
>>
>>> On 6 Jan 2016, at 09:48, Graham Dumpleton
>>> wrote:
>>>
>>> If this does solve the push issue, what is
All,
Thanks so much for your feedback to my original request for comments on the
future of WSGI. You provided a ton of really useful feedback: when printed out
on my printer it ended up at about 50 pages of information that was really
engaging reading. I also want to thank you all for keeping t
> On 20 Jan 2016, at 06:04, Graham Dumpleton wrote:
>
> For response content, if a WSGI application currently doesn’t set a
> Content-Length on response, A HTTP/1.1 web server is at liberty to chunk the
> response.
>
> So I am not sure what is missing.
My specific concern is the distinction
> On 20 Jan 2016, at 11:25, André Malo wrote:
>
> Those APIs are just broken then. The HTTP RFCs state very clearly [1], that
> any hop may modify the transfer encoding. In other words: the transfer
> encoding is transparent to the representation layer.
That’s a good point, and seems like as go
> On 21 Jan 2016, at 06:39, Benoit Chesneau wrote:
>
> because i am not speaking about making a specification, but a way to expose
> in the API (environ) custom extensions that a server want to experiment.
> there are actually no easy way except checking "wsgi." indeed but that
> doesn't make
All,
After having had a fairly useful discussion with you all over the past few
weeks, I’ve begun working on the next draft of the WSGI PEP, WSGI 1.1. This
work is being tracked in a GitHub repository[0]. Currently, I’ve made a few
changes directly on the master branch that I believe are editor
thought you were saying the first time I saw backward-incompatible in the
> text).
>
> On Wed, Feb 17, 2016 at 6:55 AM, Dirkjan Ochtman <mailto:dirk...@ochtman.nl>> wrote:
> On Wed, Feb 17, 2016 at 12:51 PM, Cory Benfield <mailto:c...@lukasa.co.uk>> wrote:
> > Please
> On 10 Mar 2016, at 00:34, Andrew Godwin wrote:
>
> To that end, I did some work to make the underlying mechanism Django Channels
> uses into more of a standard, which I have codenamed ASGI; while initially I
> intended for it to be a Django documented API, as I've gone further with the
> pr
> On 10 Mar 2016, at 18:36, Andrew Godwin wrote:
>
>
> Second, if it were me I’d remove the `status_text` field on the `Response`
> object. Custom status text is a terrible misfeature (especially as HTTP/2
> doesn’t support it), and in 99% of cases you’re just wasting data by
> repeatedly se
> On 10 Mar 2016, at 23:56, Andrew Godwin wrote:
>
> I would indeed want to require servers to always fold headers together into a
> comma-separated list, as that's what the RFC says, and it then means
> applications only have to deal with one kind of multi-header!
Well….kinda?
The RFC s
> On 24 Mar 2016, at 16:29, Jason Madden wrote:
> Well, here's a practical use :) And the two points above do not apply to this
> practical use, I think. (1) doesn't apply because `__repr__` is not going to
> change and isn't fancy. (2) doesn't apply because gevent keeps a reference to
> the e
> On 25 Mar 2016, at 15:04, Jason Madden wrote:
>
>
>> On Mar 25, 2016, at 05:01, Cory Benfield wrote:
>>
>> Given that gevent is keeping hold of its own reference to the environ, why
>> does gevent not simply wrap the environ dict in a class that implement
25 matches
Mail list logo
