People should be aware how much worse HTTPX performs versus Aiohttp. For high scale systems it makes a massive difference
I can attest of that, and in addition of harmful decisions of the maintainer that are loaded foot guns...
HTTPX2 – A next-generation HTTP client for Python
41–50 of 50 posts
Re: HTTPX2 – A next-generation HTTP client for Python
#42Noob question: what's the purpose of having so many request libraries? In JavaScript it's crazy, but in Python it's starting to feel the same: requests, httpx, httpx2... From my perspective, HTTP requests have been mastered for years (decades?). What's the point of switching libraries? What's so extraordinary about the new HTTP library that makes requests look crap? I understand that new protocols appear from time to…
`requests` has a friendlier API than the standard library. However, it does not support newer versions of HTTP, nor does it support `async`. The maintainer considers it complete, feature-frozen software, IIRC - they'd rather keep it stable for existing users and let other libraries succeed it. `aiohttp` supports `async` but was never popular for non-async `httpx` supported newer HTTP versions and both async and non-a…
'urllib3' completely saved me once. We had to authenticate with the border proxy using a certificate, then make a request to a web service ... that needed authenticating with a certificate. Urllib3 was the only one that could do it.
Re: HTTPX2 – A next-generation HTTP client for Python
#43I thought we all moved over to Niquests and/or aiocquic and HTTP/3 these days.
Re: HTTPX2 – A next-generation HTTP client for Python
#44Earlier quoted context omitted.
thanks for the summary. >`httpx` supported newer HTTP versions and both async and non-async. However the maintainer decided to close all outside submissions, issues and discussions for personal reasons. how can something like this happen? and which positive consequence there can be out of that?
> how can something like this happen? https://xkcd.com/2347 Specifically in this case, the consensus seems to be the maintainer is having some mental health struggles and chose to close out outside contribution.
ohh thanks for that xkcd! totally right!
only problem I have and that's probably why I didn't associate it directly myself is that I see the example very valid for many other FOSS cases.
but in this case it feels like the part at the bottom is made of multiple random persons, not a single one, and one of those random persons decided to exclude all the other random persons.
so maybe the lower layer shall be represented as made of multiple pieces that fight each other, beside the all modern shit on top of it.
Re: HTTPX2 – A next-generation HTTP client for Python
#45Earlier quoted context omitted.
Yep. All HTTP/2 features are subsumed by HTTP/3 and all HTTP/2 deployments should be focusing their effort on moving to HTTP/3. HTTP/2 is full of growing pains and fiddly kernel config for it to perform better than even HTTP/1.1. Moving these dependencies into userland was the path that HTTP/3 took and it has proven itself through CDN and browser adoption for years now. I’d go as far as to say that we need to reevalu…
HTTP/3 is fundamentally a different architecture than /2. To fully embrace it requires rethinking backend design significantly; just bumping a version number on HTTP without utilizing the intention of the spec is incorrect. HTTP/1.x is not obsolete. It fills a very relevant request structure that most of the Internet still runs on.
Seems like the major gripe is over my usage of the word “obsolete” instead of “deprecated”. We could all be flipping switches instead of tapping on MacBooks but you gotta draw a line somewhere.
Re: HTTPX2 – A next-generation HTTP client for Python
#46Earlier quoted context omitted.
Yep. All HTTP/2 features are subsumed by HTTP/3 and all HTTP/2 deployments should be focusing their effort on moving to HTTP/3. HTTP/2 is full of growing pains and fiddly kernel config for it to perform better than even HTTP/1.1. Moving these dependencies into userland was the path that HTTP/3 took and it has proven itself through CDN and browser adoption for years now. I’d go as far as to say that we need to reevalu…
Hmm, I'd define that as "deprecated", not "obsolete". Many extant H2 deployments are stable and performant, and if they're eg fronted by an H3 CDN, the migration ROI might be questionable. /$.02
Context: spent my career building CDNs at Cloudflare/facebook/pinterest.
The h3 juice is worth the squeeze. 0rtt TLS, BBR, HPACK, etc. You can roughly achieve this with a carefully configured h2 deployment across multiple layers and packages or just move to h3 and let the app layer handle it all. We baked all of the best practices into h3, the world just needs to move on.
Re: HTTPX2 – A next-generation HTTP client for Python
#47People should be aware how much worse HTTPX performs versus Aiohttp. For high scale systems it makes a massive difference
[dead]
Re: HTTPX2 – A next-generation HTTP client for Python
#48Earlier quoted context omitted.
`requests` has a friendlier API than the standard library. However, it does not support newer versions of HTTP, nor does it support `async`. The maintainer considers it complete, feature-frozen software, IIRC - they'd rather keep it stable for existing users and let other libraries succeed it. `aiohttp` supports `async` but was never popular for non-async `httpx` supported newer HTTP versions and both async and non-a…
'urllib3' completely saved me once. We had to authenticate with the border proxy using a certificate, then make a request to a web service ... that needed authenticating with a certificate. Urllib3 was the only one that could do it.
I've had to do similar in the past, and also wound up on urllib3.
Re: HTTPX2 – A next-generation HTTP client for Python
#49Noob question: what's the purpose of having so many request libraries? In JavaScript it's crazy, but in Python it's starting to feel the same: requests, httpx, httpx2... From my perspective, HTTP requests have been mastered for years (decades?). What's the point of switching libraries? What's so extraordinary about the new HTTP library that makes requests look crap? I understand that new protocols appear from time to…
[deleted]
Re: HTTPX2 – A next-generation HTTP client for Python
#50Noob question: what's the purpose of having so many request libraries? In JavaScript it's crazy, but in Python it's starting to feel the same: requests, httpx, httpx2... From my perspective, HTTP requests have been mastered for years (decades?). What's the point of switching libraries? What's so extraordinary about the new HTTP library that makes requests look crap? I understand that new protocols appear from time to…
Async ruins everything, as usual.