13 ms·
Nghttp3 1.0.0 – HTTP/3 library written in C
- jadayesnaamsi 3y ago[flagged]
- mbernstein 3y agoNo?
- superkuh 3y agoAfter looking around for ~5 minutes I still can't find out if this HTTP/3 lib will allow establishment of an HTTP/3 connection with a self signed cert. Or if it will allow non-encrypted connections. Does anyone know? Given the lack of any function names addressing TLS/CAs/encryption/etc I'm going to assume it's like all the other HTTP/3 implementations and fails to fully implement the spec. It's funny. Everyone defends MS/Google's HTTP/3 based on QUIC by saying the lack of ability to use plain text or self signed certs is the fault of the HTTP/3 implementations. But all the HTTP/3 lib implementations say it's the fault of QUIC.
- deleted 3y ago[deleted]
- lights0123 3y ago> Given the lack of any function names addressing TLS/CAs/encryption/etc Not only in its public API, but those are missing from its source code as well. I can't see where it could be doing any encryption—it doesn't even link to e.g. OpenSSL.
- jsnell 3y agoI don't think this is a free-standing implantation. The docs start with: > nghttp3 is a thin HTTP/3 layer over an underlying QUIC stack.
- lights0123 3y ago> I'm going to assume it's like all the other HTTP/3 implementations and fails to fully implement the spec... the lack of ability to use plain text or self signed certs Really? Does trusting a self-signed cert as a root cert not work in most libraries? quiche at least lets you control the parameters of their TLS implementation (https://docs.quic.tech/quiche/struct.Config.html#method.with_boring_ssl_ctx_builder https://docs.quic.tech/quiche/struct.Config.html#method.with...), which lets you go as far as allowing you to manually verify certs yourself (https://docs.rs/boring/latest/boring/ssl/struct.SslContextBuilder.html#method.set_verify_callback https://docs.rs/boring/latest/boring/ssl/struct.SslContextBu...).
- johncolanduoni 3y agoWhere in the HTTP/3 spec does it allow for non-encrypted connections? HTTP/3 is a mapping of HTTP semantics to QUIC specifically, and QUIC mandates TLS 1.3 negotiation. Also quiche supports self-signed certificates (I use it with them). In fact I'm not aware of any raw QUIC or HTTP/3 implementations that don't allow implementing your own certificate handling.
- tedk-42 3y agoConsidering you can't run nginx with http/2 unless you specify SSL, I'd say TLS/SSL is a requirement with this library.
- ahoka 3y agoJust create your own root CA and pin it in the clients.
- superkuh 3y agoHow do I host a website visitable by random people I've never met on HTTP/3 without getting the continued/periodic approval of a third party corporation for a CA based TLS cert? I can't. That's bad. It's a very significant change from HTTP/1.1 (HTTP/2 is only used by corporations/institutions/non-human persons) in the past which allowed anyone to connect to anyone. It was truly a web. There's absolutely no way I can get my self-made root cert in the trust store of the major browsers so that a random person I've never met can connect. HTTP/3 is designed for the use cases of non-human persons. For human persons it's a terrible protocol.
- codewiz 3y agoHow about using a memory-safe HTTP/3 implementation which is also callable from C or any other language? https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche
- codewiz 3y agoC API: https://github.com/cloudflare/quiche/blob/master/quiche/include/quiche.h https://github.com/cloudflare/quiche/blob/master/quiche/incl...
- mgaunard 3y ago[flagged]
- adgjlsfhk1 3y agoMost languages are memory safe. Literally every language with a GC is. C and C++ are pretty much the only 2 languages that are not memory safe by default.
- tczMUFlmoNk 3y agoGo is famously not memory safe. Not only can you trivially create data races, if you data race on an interface fat pointer then you can corrupt its vtable (entirely in "safe" code; no `unsafe.Pointer`). It is of course better at memory safety than C and C++, but these issues do come up in real deployments.
- throwaway892238 3y agoIt's going to be sad when the browser oligarchs deprecate HTTP/1.1. The last web protocol that humans could understand. But, perhaps it will force people to go back to the drawing board and develop new protocols that aren't dependent on web browser tech. Maybe the state of the art will finally advance past this networked document reader.
- __MatrixMan__ 3y agoI've been working on such a protocol. I can't wait to turn my back on browsers forever.
- cal85 3y agoSay more? What kind of protocol do you mean, and what comes after browsers?
- __MatrixMan__ 3y ago"turn my back on browsers" was perhaps hyperbole. I do want to make them irrelevant, but realistically I'm just targeting a subset of their domain. I'm still getting a handle on the idea, so pardon the lack of brevity. One day I'll be able to put it succinctly. Working title: Semantic Paint. --- The plan is to take what our web does poorly and do those things well. From that I have two main goals, the first of which is: Permissionless Annotation -- I should be able to attach annotations to datasets (or subsets thereof) that I find in the wild without having write access to those datasets. Links are implemented as annotations (as are edits). Unlike our web, they are undirected and might link more than two things. Instead of a directed graph between documents we now have simplices which connect (sub)sequences of arbitrary bytes. These connections are typed (I'm calling these types "colors"). Have you ever played Mad Libs? It's a game which has partial sentences, like: "____ had a great time ____ing the ______". Fun is had by filling in the words before you know the sentence and then laughing about how silly the sentence is. In semantic paint, colors are like that: they're tuples with an associated partial sentence, each tuple element goes with a blank. At any one moment, your client will be configured to display (or act on) one or more "colors". A color is a list of tuples in this form. So you might have a 3-color: ______ (code) is malicious, writing it to stdin of ______ (executable code) with ______ (parameters) will write a non-malicious copy to stdout. This color would be used for annotating malicious javascript with enough metadata to fix it automatically. It functions as a link between three items. If you have any one of them, you can find the other two. Here's the browser-killing part: at some point we stop annotating the malicious parts so that we can cleanse them, and instead we target the desirable parts so that we can make them more accessible. Embrace, enhance, extinguish. Note that we're not talking about the filename or the server whence the malicious script came, we're talking about the data itself. Naming things is hard, so I want to see how far we can get without naming them at all. Instead, a user can just just point at the thing without naming it, and apply paint---er apply annotations--to the thing they're pointing at. It operates on fragments of data scraped from a screen, tee'd from a pipe, or OCR'd from a camera--not on files or other named abstractions. The tuple values are pairs: a cryptographic hash, and a list of features that come out of a rolling hash (think rsync). The later is used to re-anchor the tuple (brushstroke) even if the canvas is paginated differently or has other small differences. Fingers crossed: I can keep false positives down to a tolerable level. For instance, if you copy some code from stackoverflow into your project, and later I annotate that code while browsing stackoverflow, you should then see my annotations on your code as viewed in your IDE (that is, provided you have opted in to seeing my paint, and are running your IDE through a semantic paint client--software which will sit between you and the IDE. The first draft is shaping up to resemble tmux). One could imagine similar functionality on a piece of paper you found blowing in the wind. Point your camera at it, extract the features, query... maybe there are annotations on that text which will tell you more about its origins. If Fermat had had this tech, he wouldn't have complained about the margin being too small, he'd just have linked the proof with a brushstroke. Imagine also people with allergies leaving annotations on menus at restaurants: "they say this doesn't have gluten, but it totally does," that sort of thing. In this sense you can think of it as a sort of distributed search algorithm, where either a cryptographic hash of content, or this list of fuzzy-hash features, is the search query. You'd just sort of leave it running as a filter over whatever data you're working with. I kind of imagine it like augmented reality... for data. --- The second thing I want do do well is Partition Tolerance. I want apps using this protocol to function without a persistent internet connection. They'll function slowly, but how up-to-date do you really need that blog post to be anyway? For most things, days or even weeks of latency is ok. If you're in your car, stopped at a light, your device will be gossiping with others that are stopped at the same stoplight. Pedestrians in range may also end up participating. Delivery drivers put nodes on their vans, which silently gossip brushstrokes while the drivers deliver packages. Imagine a train full of people with gossiping devices... Sneakernet, on autopilot, even in a disaster or a protest. Secure Scuttlebutt Protocol comes to mind here, but that's append-only. This is unordered. You just grab all of the brushstrokes you're interested in and provide strokes that your peers are interested in. Retention policies and algorithms for deciding what "interested in" means, are the domain of the app. Convergence will be hard to orchestrate, but that's no reason not to try (or maybe instead we diverge). Peers come and go, but since everything is content addressed (cryptographically, or fuzzily), what really matters is whether those peers are interested in the same colors that you are. I know it sounds crazy ambitious, but if you don't have to protect the referential integrity of a globally consistent name, lots of problems go away. The goal is to keep data nearest the things in the real world that it is relevant to. If you run across contradictory entries within a color, you can scrutinize by author (who do you trust more?) or by which peers gossiped it (which is more local?). I anticipate that handling trust explicitly like this (and focusing on data, not server names) will change the game re: misinformation. One thing I like about this strategy is that you can synchronize this gossip (like cicadas synchronize their mating habits). I want to be ad-hoc wifi/bluetooth tolerant, but now imagine a node running in the cloud. Rather than leaving it on 24/7 so that you're ready to respond to a user at any moment, you can have your node on a 5 minute cycle: Sleep for 4:30, gossip for 0:30, repeat. That's paying ten cents instead of a dollar for server uptime. Yeah, users will have to tolerate data that's 5 minutes stale, but for most applications that's fine. If the data is relevant to them, it should make it to their node before they go to look for it. Another benefit is that you can enlist your node to someone else's cause without having to talk with them first. Much like how IPFS lets you "pin" data published by somebody else so that that data doesn't go away if their node goes offline, you could instruct your node to notice square pegs and square holes and publish annotations about having fitted the peg in the hole. This means that if you don't want to pay somebody in money, you can instead pay them in operational support: > I don't want to pay you $5 / mo. Instead I've been hosting way more than my share of your service on this stack of hard disks for a month. Let that be my payment. I think there are some things that capitalism and zero-sum games are doing poorly, that cooperation and reciprocity could do well. That idea is not fundamental to the protocol, but it is fundamental to why I want to build the protocol. ---- Whew, I could go for pages and pages, but that's my best shot at a sketch. Thanks for asking, sorry it's not elevator-pitch-grade.
- keepamovin 3y agoSorry for what's probably a dumb question, but why do some of these start with 'ng'? Like nginx, and now this?
- iampims 3y agong is a common shortcut for "Next Generation" (ex: syslog-ng…)
- tsuru 3y agoUnless in Japan where it means "no good" hence :NG emoji:
- keepamovin 3y agoO-oh, thank you! :)
- queuebert 3y agoFor me it means 'not gonna'.
- panzi 3y agoOr Star Trek TNG.
- WirelessGigabit 3y agoEngine. https://en.wikipedia.org/wiki/Nginx https://en.wikipedia.org/wiki/Nginx Nginx (pronounced "engine x"...
- phyzome 3y agoIt's hard for me to imagine using any new network-touching software written in C. We have safer options now...
- FpUser 3y ago>"It's hard for me to imagine " Simple solution - don't
- 1vuio0pswjnm7 3y agonghttp3 is not new software. nghttp3 can be used to create qpack standalone binary which does not touch the network. https://raw.githubusercontent.com/ngtcp2/nghttp3/main/examples/qpack.cc https://raw.githubusercontent.com/ngtcp2/nghttp3/main/exampl...
- p-e-w 3y agoNot that it matters. OpenSSL was already 15 years old when Heartbleed was discovered, and the horrible code that caused it remained unnoticed for two years. The idea that software maturity and "enough eyes" can overcome the glaring problems from using memory-unsafe programming languages is a fantasy.
- anuraaga 3y agoI believe the point is that this is http/3 support added to the nghttp2 library which has been around for a long time, longer than Rust's mainstream popularity started to build. While I haven't used it personally I have heard good things about the library it's good to see it continue. Dismissing a new feature in an existing library seems quite excessive and possibly zealous. Or perhaps we should just stop using OSes entirely because they continue to release new features in memory unsafe languages.
- lemper 3y agojust don't. and I am waiting for your contribution in free and open source software to write correct, safe, and performant in Ada. It'd be much more welcome if you write the formal business requirements in Spark. Rust? why would want to write SAFE software in a language without formal spec? I question the morality af those people.
- Ayesh 3y agoFunny, I saw this on HN while I was taking a break from testing Caddy, which has HTTP/3 support, and is even enabled by default. I suppose it's based on Go's implementation. I'm using Apache at the moment and it's working great. HTTP/3 isn't even in the horizon for Apache, and it is the reason why I'm trying out Caddy/Nginx/OpenLitepseed in the first place. Would nghttp3 eventually bring HTTP/3 to Apache?
- KronisLV 3y ago> I'm using Apache at the moment and it's working great. You know, Apache is pretty decent. I'm actually surprised that they added ACME functionality with mod_md before Nginx, so now you can get Let's Encrypt certs without the need for certbot: https://httpd.apache.org/docs/2.4/mod/mod_md.html https://httpd.apache.org/docs/2.4/mod/mod_md.html If you turn off .htaccess the performance is okay as well (closer to how Nginx has nginx.conf), their mod_security performs pretty well and I'm not sure of that many alternatives to mod_auth_openidc elsewhere. Of course, Nginx, Caddy and other web servers are really nice too!
- Ayesh 3y agoYeah I've built quite a lot of muscle memory having used Apache for about a decade too, and the configuration felt quite intuitive, but Caddy's configuration is such a fresh breath and I'm really enjoying it so far. More than Apache's to be honest.
- apitman 3y agoActually, the go stdlib doesn't support it yet. Here's the relevant issue, including some perspective by caddy's lead developer: https://github.com/golang/go/issues/32204 https://github.com/golang/go/issues/32204
- eigenvalue 3y agoI’m a big fan of nginx. Incredibly fast and reliable. But it doesn’t support HTTP/3 out of the box using the distributions available from system package managers like apt.
- jedisct1 3y agoVery cool! And congrats for reaching version 1.0.0! Other nice HTTP/3 libraries include H2O: https://h2o.examp1e.net https://h2o.examp1e.net as well as Facebook/Meta ProxyGen: https://github.com/facebook/proxygen https://github.com/facebook/proxygen
- ksec 3y ago>Other nice HTTP/3 libraries include H2O: But H20 hasn't been updated for years. 2.3 Beta 2 was released in 2019.
- jedisct1 3y agoIt's constantly updated https://github.com/h2o/h2o/commits/master https://github.com/h2o/h2o/commits/master Also see: "switch to a new release model" https://github.com/h2o/h2o/issues/3230 https://github.com/h2o/h2o/issues/3230 "Every commit to the master branch is considered ready for production"
- ksec 3y agoOH That is great. I really wish this was better known though. They could have at least make a version 2.3 Release or 3.0 release with that announcement.
- 19h 3y agoThere are constant updates; its author (Kazuho Oku) is working for Fastly. H2O is absolutely battle proof -- its h2 and h3 implementation perform amazingly well.
- mkl95 3y agoHow does it compare to https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche?
- Alifatisk 3y agoCan turn this into a C extension for Ruby or will it be to messy?
- Asmod4n 3y agoJust skimmed over the API reference page, looks useable from ruby.
- fideloper 3y agoHmmmm but is it time for a new domain?
- deleted 3y ago[deleted]