[HN Gopher] Nginx 1.25.0: experimental HTTP/3 support
___________________________________________________________________
Nginx 1.25.0: experimental HTTP/3 support
Author : thunderbong
Score : 193 points
Date : 2023-05-23 17:19 UTC (5 hours ago)
(HTM) web link (nginx.org)
(TXT) w3m dump (nginx.org)
| teaearlgraycold wrote:
| Anyone else used to pronounce it "en-ginks"? It wasn't until I
| started working as a web developer that I learned the truth. And
| it took me a minute to piece together that "engine X" was the
| same thing.
| andersrs wrote:
| I say Engine X. Enjinks is cute. As long as you don't say "you-
| buntu" we can be friends.
| Eumenes wrote:
| always cute to hear a recruiter pronounce it
| alphabet9000 wrote:
| it will always be "en jinks" to me
| compilator1 wrote:
| Only .htaccess support is missing from nginx. Good web server.
| mtmail wrote:
| Related (opinionated)
| https://www.nginx.com/resources/wiki/start/topics/examples/l...
| "Stop using .htaccess. It's horrible for performance. NGINX is
| designed to be efficient"
| networked wrote:
| _.htaccess_ doesn 't have to affect performance; this is more
| of a historical artifact. With an HTTP server expecting a
| read-only site root, you could only read every _.htaccess_
| once, when you replaced the site root filesystem with a new
| version. A user could still see a read-write filesystem, only
| with a "save" button (command, etc.) that created and
| mounted a new read-only site root.
|
| While it is a performance and security burden, people reject
| .htaccess is too readily. It has enabled users who aren't
| quite programmers to assemble sites out of web applications
| and components that live in different subdirectories. It has
| clear value. (Not that I think nginx should implement it.)
| SahAssar wrote:
| > With an HTTP server expecting a read-only site root, you
| could only read every .htaccess once, when you replaced the
| site root filesystem with a new version
|
| In that case you would still need some way to trigger a
| reload of the htaccess, right?
|
| If so, is there a usability difference to just including
| nginx configs on the same locations?
| bandrami wrote:
| I think the bigger issue is that the use case .htaccess was
| designed for (multiple users sharing a single physical
| server) just isn't really a thing anymore AFAIK. If you're
| just managing rules in your own container somewhere,
| there's no sense keeping the logic in multiple places.
| foverzar wrote:
| > This happens for EVERY request.
|
| It doesn't need to, though.
|
| These days you only need .htaccess for compatibility with old
| PHP apps. Stacking another instance of Apache on top feels
| bloated.
| piperswe wrote:
| For those old PHP apps, you can probably convert the
| .htaccess into nginx config.
| minusf wrote:
| .htaccess is self inflicted pain, no need to downvote :)
| pseudosavant wrote:
| nginx conf is self-inflicted pain...
| whalesalad wrote:
| 2006 called and would like you to come back
| andersrs wrote:
| [flagged]
| iknowstuff wrote:
| Is there anything like nginx based on hyper?
| 0x457 wrote:
| linkerd2 proxy uses hyper, but I don't know where exactly.
| stusmall wrote:
| While I don't think it is hyper based there is this built in
| rust: https://www.sozu.io/
|
| I haven't used it so I can't vouch for the quality.
| [deleted]
| shmoe wrote:
| So this is QUIC, right?
| markdog12 wrote:
| Well, HTTP 3 is standardized off the initial QUIC
| implementation (UDP), yes.
|
| Update: I guess, technically, HTTP 3 is the protocol built on
| top of the QUIC protocol.
| jupp0r wrote:
| Exactly, it uses QUIC as the transport layer. You can do more
| with QUIC, there are beta implementations to use it for
| WebRTC data channels[1] and there have been experiments to
| use it for for WebRTC media transport, for example[2].
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/API/WebRTC_API/...
|
| [2] https://www.w3.org/2011/04/webrtc/wiki/images/6/69/Media_
| ove...
| superkuh wrote:
| Essentially. It's HTTP semantics on top of QUIC on top of UDP.
| Google and Microsoft open-washed their implementions designed
| for mega-corp use cases through the IETF and now it's called
| HTTP/3. One special feature of HTTP/3 as implemented that's
| really good for for-profit use cases but terrible for human
| person use cases is that it cannot establish a connection to a
| non-CA TLS endpoint. That is, you want a random internet
| visitor to be able to visit your HTTP/3 website, you have to
| get continued approval from a third party incorporated CA. This
| makes it pretty much useless for things like IoT and human uses
| at home. But it's great for things involving money.
| still_grokking wrote:
| Could you please stop spreading uninformed FUD?
|
| > it cannot establish a connection to a non-CA TLS endpoint
|
| That's plain wrong. Self signed certificates and internal CAs
| work just fine.
|
| The whole point of HTTP/3 is: You _can 't establish an
| unencrypted_ connection. And that's a very good idea!
|
| I'm running at the very moment a HTTP/3 development server on
| this machine here. I did not have to ask anybody for
| allowance to do so.
|
| (Actually I'm right now building a WebTransport server.
| WebTransport has even more strict rules for certificates but
| even there it's still possible to connect to an endpoint that
| uses a self-signed cert that isn't signed by any CA cert.)
| nixcraft wrote:
| I guess, now is the ideal time for me to experiment with LXD or
| Docker images that are based on Alpine Linux or Debian Slim for
| QUIC support for Nginx.
| jpgvm wrote:
| Debian Slim all the way. musl is only good when you are
| building for and testing against musl. Third party software on
| musl has burnt me enough times to know that sticking to glibc
| is the way to go unless you like that sort of pain.
|
| Footnote: I actually love musl, just for my own software that
| explicitly targets it and is validated against it.
| still_grokking wrote:
| I would strongly avoid Alpine.
|
| Most software isn't written with Musl in mind! And that shows.
|
| You can run in all kinds of extremely hard to debug issues and
| especially massive performance problems. Stuff may slow down to
| fractions of the performance comparison to regular Linux
| distros.
|
| If you want maximal small containers go with Distroless.
| perbu wrote:
| I am not at all convinced that the measly 1-4% performance we'll
| manage to eek out of this is worth the effort and complexity.
| intelVISA wrote:
| Bear in mind QUIC was primarily designed to improve
| advertisement penetration by making it harder for good actors
| to interdict and remove bad domains. (Something like dns-over-
| http/3 is, allegedly, referred to internally at Google as the
| anti-Pi-hole)
|
| plus, in real-world use cases it's probably a perf loss running
| TLS like this fwiw.
| still_grokking wrote:
| > Bear in mind QUIC was primarily designed to improve
| advertisement penetration by making it harder for good actors
| to interdict and remove bad domains.
|
| Are there any prove points for this claim besides this shout-
| out?
|
| QUIC is more like a modern TCP. What you do with such a
| protocol is unrelated to the protocol as such. You can open
| secure connections and stream data with it. That's all.
| Everything else is on the application side.
|
| > Something like dns-over-http/3 is, allegedly, referred to
| internally at Google as the anti-Pi-hole
|
| This claim sounds like anti QUIC FUD.
|
| Nothing can stop you from using a Pi-hole like device as your
| primary DNS resolver!
|
| (OK, I admit Google could try to hard-code their DNS servers
| in Chrome. But I'm very unsure they would make it through the
| following shit storm in one piece.)
| dochtman wrote:
| Latency at higher percentiles (crappier internet connections)
| improves pretty meaningfully in most of the articles I've seen.
| Here's a recent one from Dropbox:
|
| https://dropbox.tech/frontend/investigating-the-impact-of-ht...
|
| (Discussed at https://news.ycombinator.com/item?id=36027702.)
| robocat wrote:
| Quote from article: For the majority of our
| global users, HTTP3 reduced network latencies by 5-15ms (or
| 5%). While this is an improvement, these wins would appear
| negligible to the average user. At p90, however, HTTP3
| demonstrated massive improvements, with a latency reduction
| of 48ms (or 13%)--and at p95, a reduction of 146ms (21%).
| This could be explained by the fact that HTTP3 is better at
| handling packet drops in parallel connections by eliminating
| head-of-line blocking; because packet drops are more likely
| to occur in networks with suboptimal connection quality, the
| benefits of HTTP3 are more visible at the higher percentiles.
| still_grokking wrote:
| Given that the majority of people uses the web through very
| often quite crappy mobile links HTTP/3 is actually a
| significant win from the user experience perspective. It
| can be all the difference between "site is completely
| unusable" and "site is slow, but you get through".
|
| Of course it's true that QUIC is a complexity monster. OTOH
| HTTP/3 is actually quite simple when you have the QUIC
| layer implemented. A simple HTTP/3 server is no more than
| this:
|
| https://github.com/aiortc/aioquic/blob/main/examples/http3_
| s...
| ignoramous wrote:
| QUIC is also more of a response to the havoc wreaked by network
| middleware, ageing kernel network stacks, and arbitrary
| censorship. In another sense, QUIC is an attempt to revive the
| end-to-end principle.
| ledgerdev wrote:
| Interesting, how does QUIC help with 'arbitrary censorship'?
| 634636346 wrote:
| See: https://ooni.org/post/2022-quick-look-quic-censorship/
|
| I assume Google and co. will fix this if it ever starts to
| seriously benefit platforms like KiwiFarms, which in the
| last year was being blocked by CenturyLink, a major US ISP.
| I also predict these QUICfixes will be met with broad
| enthusiasm by HNers.
| jupp0r wrote:
| It mandates perfect forward secrecy TLS cipher modes
| mandatory which makes it impossible for man-in-the-middle
| hardware to intercept and read users' connections while
| still pretending to be secure.
|
| There was quite a bit of pushback on this in the IETF from
| financial institutions that think they have mandatory
| obligations to spy on their employees.
|
| Here is a relevant HN discussion thread from 2016 about TLS
| 1.3, most of which applies to HTTP/3:
| https://news.ycombinator.com/item?id=12641880
| horsawlarway wrote:
| > There was quite a bit of pushback on this in the IETF
| from financial institutions that think they have
| mandatory obligations to spy on their employees.
|
| To be fair, they do have mandatory requirements to
| prevent their employees from doing some things online in
| some cases. For example - some of the rules around
| coordination on a trading floor:
| https://www.sec.gov/rules/sro/nyse/2017/34-80374-ex5.pdf
|
| Or - in many cases they are legally required to retain a
| copy of communications sent, and there are a large number
| of sites that offer diverse services banks want that also
| happen to have "chat/email" hidden as a feature. That's
| legally communication, and they often can't collect and
| retain it.
|
| Long story short - they don't really care so much,
| because many of them are already doing this collection
| now in other ways... my first job out of college 13 years
| ago was helping large banks transition this monitoring
| and policy enforcement to browser extensions (Guess who
| was grumbling about the MV3 changes in chrome, for very
| similar reasons).
|
| Now they're moving to directly adding the monitoring in
| the OS/Kernel
| betaby wrote:
| They are of course free to use http in a closed
| environment, without any encryption. Or use any internal
| proprietary protocols. There is absolutely nor reason to
| mandate the world to follow their 'requirements'.
| jupp0r wrote:
| Good to know, thanks for the perspective. I only know
| that there was huge pushback against these somewhat niche
| (but still important) requirements making TLS 1.3 less
| secure for everybody. I'm glad somebody held firm.
| still_grokking wrote:
| > Now they're moving to directly adding the monitoring in
| the OS/Kernel
|
| Does this mean financial software has root-kits build in?
| Good to know!
|
| So this means every banking computer is fundamentally
| compromised at the OS level. Let' see how long it takes
| until this backfires. Could be a nice global firework
| when it goes off.
|
| Who exactly builds those root-kits? How good are they
| protected against supply chain attacks?
| rini17 wrote:
| This also means you can tunnel http3 traffic through
| cloudflare without them decrypting it?
| ignoramous wrote:
| Well, if your intention is to use Cloudflare's network
| for your H3 tunnels, then expect an API for it soon:
| https://blog.cloudflare.com/building-privacy-into-
| internet-s...
| AlexAndScripts wrote:
| AFAIK much of cloudflare's functionality requires full
| request access. You'll still need to SSL terminate there.
| alex_duf wrote:
| And a good improvement on head of line blocking that http2
| introduced?
| heipei wrote:
| I still love nginx, but it's a damn shame they gate some really
| useful features behind their nginx plus license, namely service
| discovery via DNS SRV records, cache purge requests and request
| queueing for upstreams.
| kjs3 wrote:
| Damn shame people won't pay for features they claim to need.
| misleading1 wrote:
| Weird how Nginx is like the only webserver in the history of
| mankind that offers caching capabilities but doesn't handle
| DELETE or PURGE verbs
| benatkin wrote:
| Or maybe we just like open source...
| getcrunk wrote:
| Not all of us are enterprise customers with enterprise
| budgets. There is no middle option. It starts at 3675
| annually per instance. That's more than the price of most of
| my servers
| withinboredom wrote:
| The thing is, they aren't 'needs' just nice-to-haves that are
| provided for free with other open-source software. Thus, when
| trying to choose technology for personal projects, people
| don't choose your software. They choose a 'competitor.' Thus
| when it comes time to choose software with a green-field or
| startup, the non-free solution isn't chosen because devs
| aren't familiar with it.
|
| Literally, at work (a startup), we use Traefik (which is
| horrible imho) instead of nginx (which I've used literally
| everywhere else) because the devs who originally started this
| project had never used it on a personal project.
|
| So the issue isn't paying for it, it is about making it
| useful enough for personal projects that people use it for
| personal projects that it then gets used on professional
| projects. Right now, it is barely useful for personal
| projects unless you know what you're doing.
| heipei wrote:
| This is a great point. People use Caddy because for simple
| cases the configuration is seemingly "easy", and more
| importantly it includes Let's Encrypt out of the box. I've
| tried to argue with these users that nginx has many
| powerful (and necessary) features, to no avail. Traefik is
| a similar story: It integrates neatly with Consul for
| service discovery so it's a go-to tool for TLS termination
| in front of a service mesh.
|
| Do I personally need DNS SRV support? No, I have a
| templated Nomad config that will re-render and reload the
| nginx config if the consul upstreams change. Setting this
| up though is definitely a bigger hurdle than just
| specifying a Consul service as an upstream.
| withinboredom wrote:
| I mean, if nginx offered a free personal license that
| worked on 5 servers (which would match up to Ubuntu Pro's
| free personal license), I'd be all over that. I have 3
| servers and I'm very unlikely to dish out $500 a month,
| per server, to get nginx+, but I could sell that to my
| employer if I was already familiar with the technology or
| could convince my coworkers to go give it a try and see
| what they thought.
|
| It seems they're more interested in high-touch sales
| (which is unlikely to happen on a dev team), vs. organic
| growth.
| francislavoie wrote:
| FYI, Caddy has DNS SRV support _for free_. https://caddys
| erver.com/docs/caddyfile/directives/reverse_pr...
| jdoss wrote:
| I love paying for software features that I need, but anything
| over $100 a month is too much for my personal budget for side
| projects. For example, I really want to run HA Traefik with
| Let's Encrypt shared across three instances in my datacenter
| rack, but Traefik Enterprise is many times more than what I
| can afford to pay, so I make due with one instance because
| the service discovery features for Nomad are fantastic. Same
| for Hashicorp Vault. I'd pay $100/mo for an Enterprise Vault
| for the HSM integration.
|
| I really wish companies would come up with SMB pricing to
| help us side project hackers out so we could grow into paying
| for the bigger plans. Also, I understand why they don't. SMB
| support is a huge PITA.
| YetAnotherNick wrote:
| I think they have perfectly selected features for plus. Service
| discovery, request queueing etc. are only required above a
| certain size of backend, and in this way almost 100% of the
| hobby sites are fine with open source version. And the hobby
| sites are getting reliability and security that could only
| comes with paid service for free.
| jbaiter wrote:
| I found that most of the time it was worth the time to invest a
| few hours/days into implementing the missing feature with
| Lua/OpenResty, if there wasn't already an Open Source extension
| available on GitHub.
| artursapek wrote:
| Don't shame an amazing open source project for trying to be
| financially sustainable.
| markstos wrote:
| How would you rather the devs generate revenue?
| SteveNuts wrote:
| They're owned by F5, so selling support and services.
| perbu wrote:
| it is really, really hard to sell Nginx. their conversion
| rate is about 0%. they've tried really hard to so, but
| nobody would buy it.
| mardifoufs wrote:
| I thought they were making decent revenue now?
| hawk_ wrote:
| because they sell Plus.
| mardifoufs wrote:
| Oh, I thought their only product was plus and I didn't
| realize that the comment was referring to something else!
| Which proves the point the comment was making very well!!
| So from what I understand, they also sell regular ngnix
| support
| josephcsible wrote:
| The way that Red Hat and Nextcloud do.
| cpuguy83 wrote:
| RedHat provided an entire platform that you pay support
| for... including supporting nginx. How can nginx (the
| company) replicate the same thing?
|
| Pay for the features you want. You will be better off for
| it. Expecting every company to follow the RedHat model is
| unsustainable.
| heipei wrote:
| I'm just daydreaming here, completely understand they have a
| business to run and they probably thought long and hard about
| which features to put into which license. No criticism
| intended, just something that eventually might catch up on
| them if another http server/proxy can offer everything that
| nginx does plus the missing items.
| heipei wrote:
| And, come to think of it, some additional great features would
| be automatic TLS certs via Let's Encrypt and maybe even being
| able to use a shared cache with multiple instances of nginx.
| ivlad wrote:
| You just want to get a free ride, and they want to feed their
| kids.
| madspindel wrote:
| Try Caddy. I was mind blown when I fired up a simple
| Caddyfile + Docker and got SSL out of the box.
| mschuster91 wrote:
| LE is dead easy to integrate using Docker, the work related
| to integrating it into webservers themselves (IMO) isn't
| worth it.
| dangerlibrary wrote:
| I put off adding TLS certs to my personal website for years.
| It's just a few static files served by nginx on a server -
| there wasn't a great reason to bother, I thought.
|
| It took me almost exactly 3 minutes start to finish with
| letsencypt. Where 'start' was "I should stop putting that
| off" and typing "letsencrypt.com" into a browser, and
| 'finish' was nginx serving up https:// on all my domains. I'm
| genuinely curious what nginx could possibly do to improve the
| situation there.
| Gordonjcp wrote:
| Lots of folk have mentioned Caddy, but I'd like to also
| mention Traefik which kind of does the same thing but I
| found it to be less of a pain in the arse.
| berkle4455 wrote:
| Traefik has a very verbose config with non-sensible
| defaults; Caddy works out of the box with 1-3 lines to
| setup your domain and sensible defaults.
|
| What's the pain?
| bombcar wrote:
| Caddy does it all automatically and you don't have to
| remember to do things by hand.
| adobrawy wrote:
| Caddy targets single instances. No coordination is required
| to avoid receiving receive multiple certificates for
| multiple instances for same domain.
|
| Nginx has a profit from big business that would require
| coordination to avoid multiple certificates. For
| comparison, it is worth noting that to ensure such
| coordination, Traefik requires an Enterprise plan and a
| separate agent. Such a business also often has mechanisms
| for storing certificates, so they do not necessarily want
| to integrate it into Nginx.
| fs111 wrote:
| Check what caddy does. I think that is what op is after
| guraf wrote:
| It's true that setup is simple enough but what other
| servers like Caddy provide is automated renewals.
|
| You don't have to mess with having a .well-known always
| accessible on each domain, for example. Caddy does it for
| you and only when it's needed.
| joseph_grobbles wrote:
| [dead]
| eyegor wrote:
| Certbot is practically a one liner in a cron job once you
| fill out the config.
| fosk wrote:
| I am biased, but Kong Gateway has built SRV resolution in the
| OSS product, which runs on top of Nginx:
| https://docs.konghq.com/gateway/latest/how-kong-works/load-b...
| sneak wrote:
| Just use traefik and move on with your life. Apache and
| Sendmail and xinetd send their regards too.
| Ameo wrote:
| I've been running Cloudflare's implementation of HTTP3/QUIC
| called Quiche[1] on my server's NGINX for over a year. It powers
| several websites and has served hundreds of millions of
| responses. It was a little weird to set up, but I've not
| encountered any issues with it so far.
|
| It will be interesting to see how their native implementation
| compares.
|
| [1] https://github.com/cloudflare/quiche/tree/master/nginx
| still_grokking wrote:
| NGINX has now an own QUIC implementation? I have to look again.
|
| Implementing QUIC seems no fun and there are almost no
| implementations. Almost everybody claiming HTTP/3 support uses
| Quiche under the hood for QUIC (besides some outliers and AWS
| who are one of the very small group of orgs who have their own
| QUIC lib). I was under the impression NGINX kept building on
| the current foundations with Quiche.
| pachico wrote:
| I just wish Nginx had the good will to include decent metrics.
| The built-in stubs are far from enough.
|
| It's the main reason why I'm thinking about migrating everything
| to Caddy.
| codetrotter wrote:
| Interesting! I've been using Caddy for a while and actually
| recently went back to Nginx just because I am now self hosting
| PeerTube and there was a config file for Nginx to proxy
| PeerTube server ready made.
|
| But if Caddy can serve metrics which I can then collect with
| for example Grafana, that's very interesting!
| francislavoie wrote:
| Yep, Caddy has metrics: https://caddyserver.com/docs/metrics
|
| But caveat: we don't have maintainers who understand metrics
| currently, so it's nowhere near as good as we'd hope it to
| be. Help wanted!
| misleading1 wrote:
| Caddy's metrics have been disabled for like 9 months
| because they cause a massive performance penalty
|
| https://github.com/caddyserver/caddy/issues/4644
| francislavoie wrote:
| HTTP metrics (and only HTTP metrics, not all metrics)
| were changed to being opt-in, support wasn't removed. See
| my docs link above. But yes, there are performance
| consideration we're not satisfied with, and we need help
| to get them resolved.
| mholt wrote:
| They're not disabled, just off-by-default for now.
| getcrunk wrote:
| Here here! There are 2 or 3 other goodies they lock behind
| their paywall which I think would be prudent from them to
| release so they stop ceeding ground/mindshare.
| danwee wrote:
| I'm on the same boat. I started to use Nginx for side projects
| a while ago. When things became a little more serious and I
| needed decent metrics, my only option was to upgrade to Nginx
| Plus. So now I'm learning Caddy.
| hnwizard wrote:
| nginx has been a fantastic project ever since its launch with
| little real competition out there.
|
| That said, I've been running it since the early days, on super
| heavy production loads and never felt the need to have some
| more "decent" metrics out of it. I assume you're referring to
| real time metrics here.
|
| Most if not everything can be gathered from the logs, which
| nginx is very flexible with.
|
| I fail to understand why some missing metrics in a great
| product make you think to migrate _everything_ to Caddy?
| capableweb wrote:
| That's the issue with doing one FOSS version + one paid
| version, some things will be gated behind the paid version and
| probably never end up in the FOSS one, as it drives people to
| purchase the paid version.
|
| In this particular case, the ngx_http_api module offers way
| more monitoring options but is gated behind nginx Plus.
| brabel wrote:
| I think that if there's one feature they should put behind
| Plus, that's monitoring.
|
| Only "serious" companies need that (as a hobby project
| maintainer you probably don't need it)... and if you really
| want to make sure you don't give them a cent, you can build
| your own monitoring on top of nginx easily enough.
| malkia wrote:
| Not sure if this would help, but saw it some months ago -
| https://github.com/open-telemetry/opentelemetry-cpp-contrib/...
| - I've not used nginx myself, so not sure how viable/useful
| this is
| KRAKRISMOTT wrote:
| I wish Nginx would improve their developer experience. Their
| deployment patterns and configuration are horrid compared to
| Caddy which is amazing to use.
| supriyo-biswas wrote:
| Speaking of documentation, there's this weird edge case where
| =404 in try_files causes $args to no longer work(!) and I ended
| up wasting an entire day on it.
|
| It's too bad, I only moved away from caddy because of weird
| disconnection issues when reverse proxying certain apps.
| francislavoie wrote:
| I'm not sure I understand. Please write a bug report if you
| think you found a problem
| https://github.com/caddyserver/caddy/issues
| z3t4 wrote:
| Personally I love the nginx configuration, I find it intuitive
| and simple to work with. I for example use it to proxy traffic
| to linux network namespace or unix sockets. Nginx also have
| great performance so I use it to offload SSL/TSL connections.
| It also runs on few resources and I've used it on tiny VPS'
| with only 128MB of memory.
| zja wrote:
| Caddy has a lot of great features, but (at least as of last
| year) Nginx has the edge on documentation. Caddy's docs were
| almost useless. Hopefully they've improved since I last used
| it.
| mattbee wrote:
| The docs were brilliant for v1, it wouldn't surprise me if
| they were the spec for a great user experience and the code
| came second.
|
| Despite v2 supporting a very similar config file, the
| documentation doesn't emphasise that and tries to steer you
| towards its API, confusing JSON config syntax etc.
|
| It's still a very good web server for very few lines of
| config, but I don't relish trying to learn something new from
| its docs like I used to.
| withinboredom wrote:
| It's almost like the docs were written for someone
| upgrading from V1 (or familiar with V1) instead of a
| newcomer who knows nothing (like the V1 docs were written
| for).
| francislavoie wrote:
| That's not true. The docs are written with the
| expectation that the user understands how the web works.
| We can't reasonably teach that in our docs. Instead,
| users should read MDN for that stuff. If you were coming
| from v1, the only page that makes that assumption is the
| upgrade guide https://caddyserver.com/docs/v2-upgrade.
| Everything else is either a getting started guide, a
| tutorial, or reference docs for Caddyfile and JSON
| config.
| awestroke wrote:
| > Now you know that the Caddyfile is just converted to JSON
| for you.
|
| > The Caddyfile seems easier than JSON, but should you
| always use it? There are pros and cons to each approach.
| The answer depends on your requirements and use case.
|
| Followed by a table comparing the json and caddyfile
| approaches. What's the confusion?
| francislavoie wrote:
| > and tries to steer you towards, its API, confusing JSON
| config syntax
|
| I disagree. The docs don't do that. What you're probably
| talking about is the Getting Started guide
| https://caddyserver.com/docs/getting-started, which is a
| tour of _how Caddy works_ , so it first shows you the
| "bare-metal" look at how it works, then it introduces the
| Caddyfile which allows you to simplify your user
| experience.
|
| There's even a comparison table between the two
| https://caddyserver.com/docs/getting-started#json-vs-
| caddyfi... which explains when you'd want to use JSON (i.e.
| if you want programmable, API-based usage) or Caddyfile
| (i.e. for quick-and-simple hand-written config, 95% of
| users choose this).
|
| I recommend starting from
| https://caddyserver.com/docs/caddyfile-tutorial or
| https://caddyserver.com/docs/caddyfile/concepts to get an
| idea of how the Caddyfile works.
| SahAssar wrote:
| That might be true now, but I spent a lot of time trying
| to use caddy v2 and not being able to since the only docs
| where for json and some things where available in
| caddyfile and some in json.
|
| If it is fixed now then that is great, but it took at
| least a year (I'm guessing more) after the launch of v2.
| francislavoie wrote:
| Of course it wasn't going to be perfect at the initial
| release, nothing ever is. Caddy v2 was a complete rewrite
| from v1, so there was a lot of TODOs to polish it up.
|
| Definitely take another look now, there's been a ton of
| progress since then, 3 years ago. The initial v2 release
| was in May 2020, soon after the pandemic hit.
| SahAssar wrote:
| > Of course it wasn't going to be perfect at the initial
| release, nothing ever is
|
| What I'm trying to say is that on launch v2 was not a
| good replacement for v1, especially in the docs area.
| I've seen quite a few major version bumps in OSS, and it
| feels docs is an area that is usually neglected, and for
| quite a while (at least a year, I'd say more) the v2 docs
| where not useful for someone who had not participated in
| the caddy v2 community discussions.
|
| I'm just trying to describe what led me to go from a avid
| caddy proponent back to an nginx user.
|
| I'll take another look next time I have a project that
| needs a http/s server!
| nixcraft wrote:
| Caddy cannot be found in the default repositories of Debian
| or RHEL. This raises the question of why one would use such a
| server. Personally, I am hesitant to download a random pre-
| built executable from Github, even if it is open source. I
| would much rather use the apt or dnf version, as anything
| else seems like just another toy server.
| jakebasile wrote:
| Caddy provides their own yum repo and I'm pretty sure it's
| in EPEL too.
| garbagecoder wrote:
| Just build it from source?
| cpuguy83 wrote:
| While it is convenient to have software prebuilt in a
| trusted repo, these repos are more about providing
| toolchains. If something isn't in the repo (or the repo, as
| it often is, ie out of date) use the toolchain to build
| what you want.
| xeeeeeeeeeeenu wrote:
| >Caddy cannot be found in the default repositories of
| Debian or RHEL.
|
| Debian 12 (bookworm) will have it:
| https://packages.debian.org/bookworm/caddy
| francislavoie wrote:
| FWIW, that was created by someone not affiliated with the
| Caddy project, and looks to no longer be maintained
| (latest is v2.6.4, but it has v2.6.2). So as a maintainer
| of Caddy, I cannot recommend using that repo.
| peppermint_gum wrote:
| This is the official Debian repository. The package
| versions are frozen in each major Debian release.
| However, they may backport security and bug fixes.
|
| In practice, in the case of less popular packages, they
| do this on demand, when someone requests it in the bug
| tracker.
| francislavoie wrote:
| Well, users should know that if they report issues while
| using releases from that source, we can't reasonably help
| them, and that they should use an official release to get
| bug and security fixes promptly.
|
| I want to emphasize that we have no contact at all with
| the people maintaining that Debian package, they've never
| reached out to discuss anything. We're absolutely open to
| that (and they know where to find us, not hard to contact
| us either on GitHub, Twitter, our forums, here, etc).
| Nextgrid wrote:
| Has anyone actually done any research on how good the
| backporting of security fixes is in frozen distros?
|
| Maybe it's pretty good for very popular packages, but how
| about the more niche ones (and when it comes to Debian
| I'm not sure how popular Caddy is in their view)?
| francislavoie wrote:
| Debian's requirements for packaging of Go software is
| unreasonable. They expect every single dependency to be
| individually packaged. The total dependency chain of Caddy
| ends up being massive. We (the Caddy maintainers) don't
| have time necessary to allocate to a single distribution,
| to package and maintain every single dependency
| individually when all we want to do is ship a single static
| binary (plus some support files).
|
| Instead, we ship with our own debian repo, hosting
| graciously provided by CloudSmith
| https://caddyserver.com/docs/install#debian-ubuntu-
| raspbian. This is packaged via CD with GitHub Actions, and
| you can verify the authenticity of the build since it's
| signed by Matt Holt's GPG key.
|
| For RHEL, it's in COPR, and that's the best you'll ever get
| for similar reasons
| https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/
| mardifoufs wrote:
| What's the reasoning behind that packaging requirement on
| Debian? Thanks for working on caddy by the way! I find it
| very neat.
| francislavoie wrote:
| Honestly, I don't understand it fully. I just know the
| barrier-to-entry is too high for us to spend time on it.
| We don't have contact with any debian packaging
| maintainers that would be willing to work with us. But
| https://go-team.pages.debian.net/packaging.html is one of
| my main resources for my understanding of their
| requirements.
|
| And that goes without saying that Debian in general tends
| to release much slower than we'd be comfortable with. We
| don't want users running outdated and potentially
| insecure versions of Caddy. Best if users keep up to date
| by using a first-party installation method where we have
| control over the distribution pipeline.
| m_sahaf wrote:
| Adding to Francis input, the release artifacts (not the
| .deb packages, which are signed with Matt's key)
| published on GitHub are authenticated with Sigstore
| tooling[0]. You can verify the artifacts and the .deb
| packages were not tampered to the byte! The builds are
| reproducible and verifiable. FUD doesn't have any room to
| loiter.
|
| You can also build it from source using the `buildable`
| source archive artifact that includes all the deps so it
| can be built in air-gapped machine. Like its sibling
| artifacts, the source archive is signed, the signature is
| published, the signing certificate is available, and the
| checksum is published and also signed. What's so
| concerning?
|
| [Disclaimer: Affiliated with Caddy]
|
| [0] https://www.sigstore.dev/how-it-works
| KomoD wrote:
| Couldn't agree more, I absolutely LOVE Caddy, but the docs
| were truly awful the last time I had to look, all forums, etc
| also referenced v1 a lot which was really frustrating.
| ghoshbishakh wrote:
| I am ashamed to say that my eyes misread HTTP/3 as Web3 for a
| couple of seconds. For a moment, I was confused as to what Nginx
| has to do with Web3.
| meerita wrote:
| We are two.
| wsatb wrote:
| Considering Web3 is mostly used as a marketing scam, it usually
| has "to do" with everything.
| superkuh wrote:
| HTTP/3 is a Google/MS open-washing scam. They've successfully
| pushed a protocol designed entirely for large corporate use
| cases as a general HTTP version which is supposed to be used
| by human persons as well as corporate persons (entities). Big
| surprise, it's terrible for human person use cases.
| supriyo-biswas wrote:
| Any documentation on what parts of HTTP/3 are and aren't
| supported by this implementation?
| xfalcox wrote:
| Since OpenSSL will "never" support quic, what is this using?
| BoringSSL?
| still_grokking wrote:
| Most QUIC implementations I've seen so far indeed use
| BoringSSL.
|
| Not sure about the status quo in NGINX. They had a HTTP/3
| implementation on Quiche (a Rust lib implementing QUIC, and
| HTTP/3 as a side project, but afik NGINX never used that part,
| only the QUIC protocol implementation). But after reading a
| post here I'm not sure they still use Quiche (and with it
| BoringSSL). Maybe they have now an own QUIC implementation
| (with support for other crypto libs). But given QUIC is complex
| and therefore hard to implement I would actually expect they
| still base of their HTTP/3 efforts on the by now quite popular
| Quiche library. But I'm maybe wrong in this regard. Have to
| look into that.
| [deleted]
___________________________________________________________________
(page generated 2023-05-23 23:00 UTC)