6 ms·

I would been pleased to see this project named something else, maybe “httpx-ng” or “httpy” as I immediately link “http*2” with the obsolete http/2 protocol and

by jenders 21d ago

I would been pleased to see this project named something else, maybe “httpx-ng” or “httpy” as I immediately link “http*2” with the obsolete http/2 protocol and not the httpx project.

brainzap 21d ago
I agree, the brain built in error correction makes it harder to read
chrisweekly 21d ago
By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3? (FWIW I agree w/ your objection to the "httpx2" name.)
- jenders 21d ago
  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 reevaluate the event loops in nginx and elsewhere to assume UDP and HTTP/3 framing instead of TCP. There are gains to be had.
  - chrisweekly 21d ago
    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
    - jenders 20d ago
      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.
  - tcdent 21d ago
    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.
    - jenders 20d ago
      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.
  - 7bit 21d ago
    [dead]
theanonymousone 21d ago
httpy is actually twofold cool for a Python HTTP client!
- jenders 21d ago
  Agreed! I love naming things :D
auvi 21d ago
Ruby has httparty. https://github.com/jnunemaker/httparty https://github.com/jnunemaker/httparty
Lindby 21d ago
There is already a popular project called httpie, so httpy would be really confusing in non written form. Beside that, i completely agree, the name could be better. https://httpie.io/ https://httpie.io/

by jenders 21d ago

I would been pleased to see this project named something else, maybe “httpx-ng” or “httpy” as I immediately link “http*2” with the obsolete http/2 protocol and not the httpx project.

brainzap 21d ago

I agree, the brain built in error correction makes it harder to read

chrisweekly 21d ago

By what definition is HTTP/2 considered obsolete? Are you suggesting it's been supplanted by H3? (FWIW I agree w/ your objection to the "httpx2" name.)

jenders 21d ago
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 reevaluate the event loops in nginx and elsewhere to assume UDP and HTTP/3 framing instead of TCP. There are gains to be had.
- chrisweekly 21d ago
  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
  - jenders 20d ago
    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.
- tcdent 21d ago
  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.
  - jenders 20d ago
    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.
- 7bit 21d ago
  [dead]

theanonymousone 21d ago

httpy is actually twofold cool for a Python HTTP client!

jenders 21d ago
Agreed! I love naming things :D

auvi 21d ago

Ruby has httparty. https://github.com/jnunemaker/httparty https://github.com/jnunemaker/httparty

Lindby 21d ago

There is already a popular project called httpie, so httpy would be really confusing in non written form. Beside that, i completely agree, the name could be better. https://httpie.io/ https://httpie.io/