I’d like to get some eyes on this: https://github.com/huge-success/sanic/pull/472
and see what we can do to get this completed. I don’t think we can reasonably add it for 18.12 LTS but I think we can get it in to 19.x, even though it may take some effort to update the code touches.
It looks like this had a lot of community support but did not ever complete the merge. It also got passes on reviews.
Yeah… this should be a top priority. No sense in having a fast “modern” async framework without full http2 support.
Is everything from master merged over to 18.12 yet that is going for the next release?
There are a number of documentation updates that have been submitted as PRs I’d like to get in.
1348, 1349, 1350 need approval. They’re good updates, no code change, worth adding in.
HTTP/2 would be huge for Sanic. But, not only should we take a look at the #472 issue you mentioned, but also for this particular issue from @tomchristie, regarding support for ASGI - which also implements HTTP/2 out of the box.
Getting the conversation back on point for HTTP/2 and pipelining …
What should our strategy be? I see two options:
Of course we could pursue them both.
I want to get a general consensus from the whole community and @core-devs because I’d like to start working on this in the next month or so.
My vote is doing it through ASGI. I think it gets us to two goals, rather than just one: we have ASGI compatibility (and the flexibility to integrate with a north/south interface that has the goal of being correct) and through that handles HTTP/2 integration.
ETA: the ASGI 2.0 docs were just released on 2018/10/24 so it gives us a good impetus to start implementing that going forward just based on timing. https://media.readthedocs.org/pdf/asgi/latest/asgi.pdf
I’d like to also encourage you to adopt ASGI, which I think Tom has really justified the reasons for in #1265. I’ve a vested interest in the community adopting ASGI as I’m the author of Hypercorn; an existing HTTP/2 ASGI server. If you have any questions about ASGI I’ll try to help answer them.
@pgjones Awesome! Thanks for the heads up. I made a separate branch on my local last night to start playing with #1265 and generating some tests for it. If you have any tripping points or gotchas in mind, that would be great.
The more I think about this, the more I think this is the way to go. My hesitancy has been the requirement of another package in the stack to get up and running, but I think is a common enough practice using (for example) gunicorn with other frameworks in the Python world that it’s not a burden.
I agree with requiring another package and the hesitancy that goes with the bloat associated, but in this case I think it’s with good reason - it takes much of the burden off of the sanic project and its devs to assure the functionality that is being asked for by its users.
So this is how I’ve implemented the application side of ASGI in Quart. I think you’d want to focus even more than I have on performance optimization - creating tasks for example seems quite expensive. I’ll also point out this line in relation to #1176.
Server wise whilst I hope you like Hypercorn, Uvicorn is a much closer match to Sanic right now (uvloop and httptools based), and has better performance - I would think you could get sanic + uvicorn to have similar performance to Sanic today.
The other aspect I think is still a little undefined with ASGI at the moment is when to error and on what, you may find that different servers react differently - although these are the unhappy path edge cases.
Thanks for sharing the code, and thanks for decoupling your server to its own package. Cleary, one of the motivations for adopting ASGI is the benefit to the community as a whole towards adopting a standard.
And, along with that, allowing the developer to make the decision about what components to use (hypercorn, uvicorn, Daphne). Speaking for myself, and I think you and I may have had this conversation together before, I appreciate micro frameworks that are really good at the basics and nothing more: handling sockets and connections, parsing and generating requests and responses, and routing handlers.
I agree 100% percent. Sanic still is beta software, which means we should look at alternatives to make it better before saying it’s stable. If we could tackle Sanic to be ASGI compliant, this leaves the developer to choose between uvicorn / hypercorn / Daphne and us (Sanic core developers) to deal with Sanic questions (and probably nothing more). This is the wonder of decoupling and specialization 
Now that 18.12 is wrapped up, I’m going to start digging my teeth into this one. I will circle up with @tomchristie and see if he is still interested in pursuing this with us.
I’m up for it yeah, tho taking a break over the Christmas period. Gimme a nudge come Jan if I’ve not already gotten back to you.
Sure thing. Merry Christmas 