I'm just curious, is there a reason not to use a multi-stage docker build here? There are a ton of build steps, and it seems pretty tedious to have to start from scratch every time while developing the image without any layer caching.
Hi, my main task this weekend was to get it fully working. I will break down the steps over this week to utilize cache layers. I will try to get it done hopefully this week or by the weekend depending on work. Thanks a lot for your feedback.
While developing an image, I use layers as much as possible.
But usually, when the image is finished, I prefer to minimize the number of layers, it saves some (or little) storage (I think it will not > 10%).
The ARG approach to everything is really good IMO, it let you customize the final image without having to change the Dockerfile.
For example, in the OP Dockerfile, the GPG key at very least should go in an ARG.
I would suggest highlighting the experimental nature of the repo, especially if someone reaches it without going through HN. I've read the catchy "All built on the bleeding edge. Built on the edge, for the edge." but IMO it doesn't really sound like a warning that this may not be suitable for serious production use.
I've played around with the nginx cloudflare patches and quiche, and it all seems to work just fine in my lab setup.
I don't like having to apply third party patches to any mission critical software such as nginx. So I'll wait until nginx releases official support for linking the quiche library, like they did with brotli.
Good news, any participants under your control can (and so should) refuse to do 0RTT. Clients can choose never to send early data and servers can choose to always reject it, everything still works.
At the API layer reject any libraries or tools that try to foist this on you, many today either don't do 0RTT or correctly offer it as a separate API call for those willing to pay a price in terms of Replay resistance.
Well, "ssl_early_data" is opt-in. If you enable it on a virtualhost, then you also need to look at the "Early-Data" request header in your backend and make a decision there. e.g. process GET requests, otherwise send HTTP 425 Too Early.
It does seem a bit unsafe. An administrator might opt-in because they copy-pasted it from a tutorial, and not understand or pay attention to the second part.
This is great, and I'll be using it for development! However, I've been looking for something a bit more predictable, and yet still modern, for production use. I do not know why Brotli support isn't included in every nginx image at this point.
From WP I get the impression that the work-in-progress now called HTTP/3 was not necessarily designed supposed to supplant HTTP/2:
> On 28 October 2018 in a mailing list discussion, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Groups, made the official request to rename HTTP-over-QUIC as HTTP/3 to "clearly identify it as another binding of HTTP semantics to the wire protocol ... so people understand its separation from QUIC"
Any opinions on how things are likely to play out?
I believe this is the separation of the transport layer protocol (QUIC) from the application layer protocol (HTTP/3). QUIC can be seen as a replacement for TCP. HTTP over QUIC then becomes HTTP/3 - with improvements in latency and head-of-line blocking over HTTP/2. So in that sense it will supplant HTTP/2 as QUIC gets adopted more widely.
Yes, it's "almost" comical. The advantage of having a CDN with a pop in every city, vs. just having 3 or 4 well placed POP's around the world will be marginal once HTTP3 is broadly supported.
I haven't been following the TLS1.3 development. What is the current state of SNI encryption? Is it possible to encrypt the name of the host you're trying to connect to?
Would you mind reading those and taking the spirit of this site to heart when commenting here? We're trying for a bit better than internet default, and sarcastic dismissals push things in the wrong direction.
Your comment downthread (https://news.ycombinator.com/item?id=21308453) also broke the guidelines. We're really trying to avoid flamewars here, for the same reason that cities avoid flaming buildings. If you'd respect that in the future we'll be grateful.
Correct, no one is making an argument against what you said, because everyone understands that point. For most people, it doesn't need to be said. No one is ripping out production infrastructure and replacing it with this image. There's no comment anywhere suggesting it.
What you're doing is called "preaching to the choir". You're trying to be a contrarian to show everyone how smart and mature you are. Yolo, amirite? But not you! You're thoughtful and have experience and know not to do this! You're still running Debian Stable!
But really, this is just a cool Show HN project, posted on a Sunday night, and no one cares about your thoughts on the risk of bleeding edge. So they downvote and move on.
[+] [-] mnutt|6 years ago|reply
[+] [-] ranadeep|6 years ago|reply
[+] [-] chung1905|6 years ago|reply
[+] [-] ricardbejarano|6 years ago|reply
There's some features you could easily add to yours in order to make it a better overall image.
[1] https://github.com/ricardbejarano/nginx
[+] [-] darkwater|6 years ago|reply
[+] [-] ranadeep|6 years ago|reply
[+] [-] cafxx|6 years ago|reply
[+] [-] zegvold|6 years ago|reply
See https://github.com/githubcdr/docker-nginx-brotli
[+] [-] LeonM|6 years ago|reply
I don't like having to apply third party patches to any mission critical software such as nginx. So I'll wait until nginx releases official support for linking the quiche library, like they did with brotli.
[+] [-] anfilt|6 years ago|reply
[+] [-] tialaramex|6 years ago|reply
At the API layer reject any libraries or tools that try to foist this on you, many today either don't do 0RTT or correctly offer it as a separate API call for those willing to pay a price in terms of Replay resistance.
[+] [-] vasilia|6 years ago|reply
[+] [-] regecks|6 years ago|reply
It does seem a bit unsafe. An administrator might opt-in because they copy-pasted it from a tutorial, and not understand or pay attention to the second part.
[+] [-] jwr|6 years ago|reply
[+] [-] fulafel|6 years ago|reply
> On 28 October 2018 in a mailing list discussion, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Groups, made the official request to rename HTTP-over-QUIC as HTTP/3 to "clearly identify it as another binding of HTTP semantics to the wire protocol ... so people understand its separation from QUIC"
Any opinions on how things are likely to play out?
[+] [-] sseth|6 years ago|reply
[+] [-] The_rationalist|6 years ago|reply
[+] [-] w-ll|6 years ago|reply
[+] [-] lbotos|6 years ago|reply
https://www.musl-libc.org/faq.html
The logo is a mussel :)
[+] [-] iikoolpp|6 years ago|reply
[+] [-] SomeOldThrow|6 years ago|reply
[+] [-] proverbialbunny|6 years ago|reply
[+] [-] sdan|6 years ago|reply
[+] [-] xmichael999|6 years ago|reply
[+] [-] djsumdog|6 years ago|reply
[+] [-] viraptor|6 years ago|reply
Not sure what's the implementation status though.
[+] [-] cafxx|6 years ago|reply
[deleted]
[+] [-] dang|6 years ago|reply
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/showhn.html
Would you mind reading those and taking the spirit of this site to heart when commenting here? We're trying for a bit better than internet default, and sarcastic dismissals push things in the wrong direction.
Your comment downthread (https://news.ycombinator.com/item?id=21308453) also broke the guidelines. We're really trying to avoid flamewars here, for the same reason that cities avoid flaming buildings. If you'd respect that in the future we'll be grateful.
[+] [-] midev|6 years ago|reply
Correct, no one is making an argument against what you said, because everyone understands that point. For most people, it doesn't need to be said. No one is ripping out production infrastructure and replacing it with this image. There's no comment anywhere suggesting it.
What you're doing is called "preaching to the choir". You're trying to be a contrarian to show everyone how smart and mature you are. Yolo, amirite? But not you! You're thoughtful and have experience and know not to do this! You're still running Debian Stable!
But really, this is just a cool Show HN project, posted on a Sunday night, and no one cares about your thoughts on the risk of bleeding edge. So they downvote and move on.
[+] [-] SteveNuts|6 years ago|reply