Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/3 is everywhere but nowhere

httptoolkit.com

Post reply on HN
Print view View original

441–450 of 504 posts

Re: HTTP/3 is everywhere but nowhere

#441

Post by CharlieDigital »

lmm wrote: post #388
hypeatei wrote: post #24

Earlier quoted context omitted.

> side note: sad that .NET and C# are not considered "major I've said it before on here, but the tech community severely underrates .NET today. It's not Windows only (and hasn't been for ~8 years) plus C# is a very nice language. F# is also an option for people who like functional languages. I'd highly recommend giving it a try if you haven't already.

It's not Windows only but it is Windows-first. Every few years I take a look but it still doesn't feel like a serious ecosystem for Linux development (in the same way that e.g. Perl might have a Windows release, but it doesn't feel really first-class). I can't think of a single .NET/C# program that people would typically run on Linux to even have the runtime installed, so no wonder people don't bother investigating t…

Definitely not Windows-first.

Last startup we built our entire backend in .NET and C#. Every dev ended up using MacBooks. We shipped to AWS t4g Arm64 Linux targets.

This mis-perception is so irrational and not based on any facts.

Re: HTTP/3 is everywhere but nowhere

#442

Post by CharlieDigital »

oaiey wrote: post #400
throwaway2037 wrote: post #369

Earlier quoted context omitted.

> sad that .NET and C# are not considered "major"... No need to be sad about that list. Java is also missing. There must be millions of enterprise programmers in the world using Java. I just checked the Java class HttpClient (a common JDK11+ HTTP client). It currently does not support HTTP/3, so add one more to the list! Ref: https://docs.oracle.com/en/java/javase/24/docs/api/java.net.... Also, most of the very best…

There is a very simple reason for not being on the list: It support HTTP/3 and the purpose of the post was to show the lack of support in common languages. .NET does not fit that list well. And it is obviously only popular in the dark matter of Enterprise Software Development.

    > And it is obviously only popular in the dark matter of Enterprise Software Development.
Well, and apparently for game development given both Godot and Unity use C# and various builds of .NET

Re: HTTP/3 is everywhere but nowhere

#443

Post by FuriouslyAdrift »

Sesse__ wrote: post #306
FuriouslyAdrift wrote: post #202

Earlier quoted context omitted.

I've gone through dozens of applications for a PI block and all been turned down. Heard the same from most of the networking people I know of. One even had their company become a LIR just so they could lock down a block. Outside of Europe I don't know anyone not FAANG sized that managed to get it done in the last few years. In my dealings with small to medium sized biz, I usually go the SDWAN route to aggregate and b…

Huh, I have one for my personal home network :-) Granted, that is in RIPE. As long as you're multihomed, how can they turn it down?

Multihoming is broken for most people in IPv6 space. It's stupid easy in IPv4.

https://blog.ipspace.net/2010/12/small-site-multihoming-in-i...

Re: HTTP/3 is everywhere but nowhere

#444

Post by einpoklum »

neonsunset wrote: post #372
einpoklum wrote: post #312

Earlier quoted context omitted.

Can you name some examples of popular .Net applications on GNU/Linux or *BSD operating systems?

Sonarr/Lidarr and Jellyfin as a start, Ryujinx was one too in game emulation space until Nintentdo DMCA'd everything into oblivion. These are user-facing applications anyway, not back-end ones which is the more common use-case of .NET (where Linux is the most popular OS).

I have not heard of these apps, but - I'll go look them up (well, the first two), and learn something. Thanks.

About back-end - I would repeat my question but I don't want to derail the conversation too far away from the original subject.

Re: HTTP/3 is everywhere but nowhere

#445

Post by einpoklum »

kstrauser wrote: post #328
einpoklum wrote: post #308

Earlier quoted context omitted.

> It removes tons of overhead and cruft Can you elaborate? Here, or with links? What kinds of overhead and cruft?

* The header is a fixed length. * You can't fragment packets. * The redundant checksum header was removed. * No more private addressing (unless you're a glutton for punishment). * No more NAT (see above). * Simpler routing. * Doesn't require DHCP. It benefits hugely from the lessons learned with IPv4.

> * No more private addressing (unless you're a glutton for punishment).

The question of whether or not you use private addressing is, AFAICT, independent of the protocol. I mean, there's no material difference between private and public addressing.

> * No more NAT (see above).

Ditto. You don't have to NAT over IPv4, and you can NAT over IPv6; and - you may want to or need to, depending on restrictions on your connection.

> * Simpler routing

In what way?

> * Doesn't require DHCP.

IPv4 doesn't require DHCP either, IIANM.

But - point taken on the other simplifications!

Re: HTTP/3 is everywhere but nowhere

#446

Post by Dylan16807 »

frollogaston wrote: post #391
Dylan16807 wrote: post #373

Earlier quoted context omitted.

There are two ways for me to interpret "simply tell your system to start using v6". If it means upgrading every program, then your plan works but it's the same as how things work today. You're telling people to do a thing, and they aren't bothering. The "simple" step isn't simple at all. If it doesn't mean upgrading every program, then your rollout fails on the last step. You start handing out longer addresses and le…

It's the second one. But legacy programs did get upgraded, so I don't see why they wouldn't under this other plan. If anything, it's easier because you're only making the address field bigger and it's not a separate case. Some routers struggled with 128-bit addrs due to memory, and could've gotten away with like 48 or 64 bits if they're using DHCP.

Lots of legacy programs, and current programs, and other things that could have been upgraded did not get upgraded. Getting to the situation where you can just flick a switch is not a realistic dream. There's not enough motivation for the average business to add support for a version that isn't in use yet.

Re: HTTP/3 is everywhere but nowhere

#447

Post by LtWorf »

hypeatei wrote: post #424
LtWorf wrote: post #375

Earlier quoted context omitted.

Until I can do apt-install, it's got a problem with availability.

I'm pretty it's just: sudo apt-get install dotnet-sdk-9.0 No?

That comes after adding an untrusted 3rd party repository no? Why are you omitting that part?

Which means that nothing written in .net will enter the real repository until that changes.

Re: HTTP/3 is everywhere but nowhere

#448

Post by LtWorf »

neonsunset wrote: post #380
LtWorf wrote: post #377

Earlier quoted context omitted.

I think being on linux and being decent on linux are not the same, and there's .net problem.

Can you link to anything recent which could support your argument?

https://learn.microsoft.com/en-us/dotnet/api/system.diagnost...

Look at this garbage API that for no reason whatsoever mirrors winapi on posix for example.

Then after you painfully wrote your linux application despite all of that, you find out that .net is not included by any linux distribution, so have fun distributing your app!

Re: HTTP/3 is everywhere but nowhere

#449

Post by mananaysiempre »

wizzwizz4 wrote: post #434
mananaysiempre wrote: post #232

Earlier quoted context omitted.

Why does saving on cookies outweigh having to go through an additional TCP slow start?

Consider HTTP semantics. If there are cookies in the request, and those cookies change, it has to be re-requested every time. If there are no cookies, the request can remain semantically compatible, so the browser's internal caching proxy can just return the cached version. There are other advantages: the article elaborates.

Per the official HTTP semantics[1,2], what you say is not true: the only header that’s (effectively) always part of Vary is Authorization, the rest are at the origin server’s discretion; so don’t set Vary: Cookie on responses corresponding to static assets and you’re golden. The article only says that some (all?) browsers will disregard this and count Cookie there as well.

Even still, the question is, what’s worse: a cacheable request that has to go through DNS and a slow-start stage because it’s to an unrelated domain, or a potentially(?) noncacheable one that can reuse the existing connection? On a fast Internet connection, the answer is nonobvious to me.

[1] https://www.rfc-editor.org/rfc/rfc9110.html#name-vary

[2] https://datatracker.ietf.org/doc/html/rfc6265#section-3

Re: HTTP/3 is everywhere but nowhere

#450

Post by LtWorf »

cyanmagenta wrote: post #72
ralferoo wrote: post #47

For me, I think the biggest issue with large scale deployment of HTTP 3 is that it increases the surface area of potentially vulnerable code that needs to be kept patched and maintained. I'd far rather have the OS provide a verified safe socket layer, and a dynamically linked SSL library, that can be easily updated without any of the application layer needing to worry about security bugs in the networking layer. Addi…

> I'd far rather have the OS provide a verified safe socket layer There is work going on right now[1] to implement the QUIC protocol in the linux kernel, which gets used in userspace via standard socket() APIs like you would with TCP. Of course, who knows if it’ll ultimately get merged in. [1] https://github.com/lxin/quic

It will not.
Post reply on HN