T0t098i3·Aug 28, 2026
It does not: https://github.com/aio-libs/aiohttp/issues/5999
In HTTPX2 – A next-generation HTTP client for Pythonaio-libs
aiohttp
Python2014–2026
aio-libs / aiohttp
aiohttp
Asynchronous HTTP client/server framework for asyncio and Python
20Distinct people
20Mentions
0Explicit recommenders
16.6KGitHub stars
What to know before exploring
What it is
Asynchronous HTTP client/server framework for asyncio and Python
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year20 dated mentions
Observed mentions: 2014-12-26 16:46:00 UTC to 2026-08-28 22:08:02 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 1 | 1 |
What Hacker News says
20 sourcesA zip bomb can be used to execute a DoS against the aiohttp server
2 points · Open discussionYou might be able to fork and use just this patch: https://github.com/aio-libs/aiohttp/pull/7835/files
I found it on this page: https://github.com/advisories/GHSA-q3qx-c6g2-7pw2
In Hackers exploit Aiohttp bug to find vulnerable networksUgh. We're forever pinned on 3.8.1 since they broke task cancellation in 3.8.3. The handling of that is frustrating, we won't be using aio http for new projects.
https://github.com/aio-libs/aiohttp/issues/6719
In Hackers exploit Aiohttp bug to find vulnerable networks> AIOHTTP: The Python int constructor is used to parse Content-Lengths and chunk-sizes, so _, +, and - are misinterpreted.
Fun. I believe the fix is incomplete here[1]. Python's int() constructor (and related methods) accepts integers comprised of any unicode numeral, for example, int("٦٦٦") == 666, and "٦٦٦".isdecimal() == True.
NB: I haven't tested this more thoroughly and I'm not sure I'm actually looking at the right diff for the fix.
[1] https://github.com/aio-libs/aiohttp/pull/7663/files#diff-197...
In Show HN: The HTTP Garden – A Parser Vulnerability Research Toolaiohttp is still work in progress but it works with a monkey patch.
https://github.com/aio-libs/aiohttp/pull/7803
In Python HTTP library 'urllib3' now works in the browserDang; I found and reported this vulnerability on June 5 (after this report was made, but before it was made public or patched), and was told that they were already aware of the bug and working on a fix. I didn't realize I'd been beaten by only 10 days!
https://github.com/aio-libs/aiohttp/issues/7312
https://github.com/nodejs/premature-disclosures/issues/4
In Node.js HTTP Request Smuggling via Empty Headers Separated by CRIs Content-Type header mandatory in HTTP response?
2 points · Open discussionIt depends of how much control I have over the topic. If:
- I know the topic well.
- I understand the domain well.
- I can picture the technology, expectations and API well.
- I have the mastery of my time and deadline.
Then yes, I do.
E.G: I'm currently making a proposal for a new API in an open source python lib called iohttp.
I have time. I have leeway. I have a good overview of the entire problem. So I can afford thinking about the API first:
https://github.com/aio-libs/aiohttp/issues/4346
Then I will write unit tests. Then I will write the code.
But that's a rare case.
Many times coding involves fiddling, trying things out, writing drafts and snippets until something seems to start to solve what you want.
Other times, you want a quick and dirty script or you have a big system, but you are ok with it to fail from time to time. The cos
Read the rest
t of testing is then not worth it. You'll be surprised of how well a company can be, and how satisfied customers says they are despite the website showing a 500 once in a while.
And you course, you have limited resources and deadlines. Unit tests are an upfront payment, and you may not be able to afford it. Like it's often the case, this means the total cost of the project will likely be higher, but the initial cost will be in your range of price. And you may very well need that.
One additional things few people talk about is how organizations can make that hard for you. You may be working in orgs where the tooling you need (CI, version system, specific testing lib...) may be refused to you. You may even be working in companies where you cannot get clear information about the domain, but get a vague specs, and the only way to design the software is to ship, see it break, and wait for customers to report to you because otherwise the marketing people don't let you talk to them. I'd say change job, but it's not the point.
At last, you have the problem of the less experienced devs. TDD is hard. It requires years of practice in the field to be done properly because you build a system in a completely abstract way. Dependency injection, inversion of control, mocking and all that stuff you need to make a properly testable system is not intuitive: you learn it on the way. Even harder is the fact you have to use it in your head since your are not coding it, but what wraps it, first. And even more terrible is the fact that baldly implemented, over used and over engineered, design patterns make problem worst, not better.
https://github.com/aio-libs/aiohttp already supports asyncio. Why do I need this for asyncio?
Anyway, I see that Issues are disabled for the repo. Is that the new way to develop? /s
In Python Requests IIII've seen a lot of debate over this, but I find greenthreads so much simpler to work with and reason about, on top of keeping my code clean and completely interoperable with my synchronous code.
This is off-topic from the current JavaScript discussion, but even though Python introduced "first-class" async support a while ago, I still exclusively use gevent [1] for all of my concurrency needs. It provides full greenthread support for Python. It's extremely performant on top of being simple and clean to integrate. In contrast, Python's asyncio and async/await feels needlessly verbose and tortuous, often with full rewrites or replacements of libraries required to actually take advantage of the features (e.g. https://github.com/requests/requests vs. https://github.com/aio-libs/aiohttp). With gevent, I can just put whatever code I want into a
Read the rest
greenthread and get instant asynchronicity (excluding hiccups with a few 3rd party libraries that have network I/O in native extensions, which is rare).
The one downside is it achieves its magic with standard library monkeypatching, which is pretty hideous, but it's done very seamlessly. Developers are able to write the exact same code with or without monkeypatching and not worry about what it's doing. I've never encountered an issue with the monkeypatching when using any standard or 3rd party library.
[1] http://www.gevent.org/
> Given some historical check-in, it is quite challenging in Git to find out what came next. It can be done, but it is sufficiently difficult and slow that nobody ever does it.
On the command line:
git for-each-ref --contains <commit, branch, etc.>
Lists all refs (branches, tags) that contain the passed argument.
I'd be curious to know the author's need for this. I've used something similar on GitHub to determine when a given commit, typically a bugfix, is released.
> There is no button in GitHub that shows the descendents of a check-in.
There is: go to the commit's URL (https://github.com/$ORG/$PROJECT/commit/$COMMIT) and below the subject & body of the commit, but above the author/commit time, there's a section that will have all branches, tags, and pull requests that the commit is a part of.
For example: https://github.com/aio-lib
Read the rest
s/aiohttp/commit/d7f0511ead6d05cf6...
That commit is part of the "master" branch, and the "v3.1.2" tag.¹
¹Note that more tags will likely appear in the future, if you're reading this comment some time from when I'm writing it.
> That seems wrong. I should be able to run normal Python code as async, right?
No, that is not the case.
To better understand this you should look at an async library, like https://github.com/aio-libs/aiohttp
Look at what it actually calls all the way down under the hood.
If it were as simple as adding `asyncio.sleep(0)`, then that library seems as though it would have been much easier to write. :P
Just look at the code you posted at the end, it actually runs faster synchronously, without `asyncio.sleep(0)`.
The sleep is what happens async, not the print statements, therefore, all you're doing is introducing delay.
Similarly, the Django ORM DB calls you make in the other examples are all still happening synchronously. However, you're just adding a delay that causes them to get picked off in an inconsistent order.
In Python3 Asyncio for middling developers> no nice async web framework
You should check out aiohttp: https://github.com/aio-libs/aiohttp
I've built a couple of tester projects with it in Python 3.5. It's actually quite pleasant.
In Why Python Is Not My Favorite Language (2016)When he brings up requests in comparison to urllib he seems to not know about aiohttp https://github.com/KeepSafe/aiohttp
In Python 3.5 and MultitaskingShowing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.