-
Hi there 👋 There are many features that we reject because of complexity it can bring to For that reason, I'd like to propose a way to implement those features, at least the ones that make sense, even if they bring complexity. The goal is to make features available, and study if they should be included in What features are we talking about?To list some:
What's the alternative here?I can implement my own HTTP class, and use with Doing the alternative approach, I'll lose the potential to understand our users' needs. How do you think this experimental approach will work?This can be thought a bit better, but the approach that I thought was to create a module called I'd also thought about sending a log message when people use this experimental feature, asking for feedback to understand their use-case, with a permanent discussion on GitHub to receive those feedbacks. Thoughts about this? @encode/maintainers |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
I like the idea of having experimental features rolled to enthusiast users.
Also, I personally feel a lot of users would benefit from support for ASGI Websocket Denial Response extension and support for HTTP/2. |
Beta Was this translation helpful? Give feedback.
-
Yes, the plugin way is good. It can reduce maintenance costs and enrich the functions of uvicorn. |
Beta Was this translation helpful? Give feedback.
-
Very well. I'll be organizing this new repository to fit the list of features. Thank you for the thoughts. 🙏 |
Beta Was this translation helpful? Give feedback.
Very well. I'll be organizing this new repository to fit the list of features.
Thank you for the thoughts. 🙏