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%).
> I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario.
That's completely different thing. Multi-stage builds are great for separating build environment from production environment, but if you need several layers for production environment, they won't be squashed. See here: https://github.com/docker/compose/issues/4235#issuecomment-3...
Yeah, I suspect that while the author could use a development image to do all of the compiling, given that all of the nginx files are not in a single directory it's my understanding that you'd need multiple COPY commands, and you'd still want to do all of the package manager operations in the prod build. It's really a tradeoff of development ease vs minimal packaged output.
> given that all of the nginx files are not in a single directory it's my understanding that you'd need multiple COPY commands
Workaround would be to move these files to one directory on host, COPY it in one command to /tmp (or even better, /dev/shm or other ramdisk) and then use script to distribute files where needed.
You can make the multi-stage builds actual images themselves, and setup your CI to auto push them to a registry. Then you can have shared multistage builds, which is pretty useful for things like compiling static libraries in their own images, and COPYing them into images that statically link to them.
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.
That's even more concerning that there are libraries that hide such a thing. There is gonna be instances that bites someone hard where said replay is not idempotent.
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.
I think it will be better to fully disable early data for people without full control of DC's network equipment. I don't know why Cloudflare made a decision about using headers and Too Early response. They have full control of their POPs. It will be better to measure RTT and use UDP based KV storage with tickets only for clients with high RTT. So for clients with RTT higher then access to KV storage it will be better to issue tickets, for other clients it will be better to drop early data and use full handshake. Currently, I'm working on a project with the same idea.
To measure RTT you need to perform a round trip. Hence the name. But the _whole point_ of this feature is to avoid incurring the cost of an extra round trip if possible.
There is no need to send extra data to measure RTT. On the TCP handshake SYN/ACK you already know RTT. Linux kernel provides this info in tcp_info data structure.
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.
Aside from lowering latency, a big "edge footprint" also naturally load-balances and allows for more specialized localization, from what I can think of off the top of my head. I don't have much practical experience here so correct me if my speculation is off, anyone.
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?
At the point where the last drafts of TLS 1.3 were shaping up, Eric (Rescorla)'s initial ideas for how to achieve eSNI had failed and the extant draft was only a problem statement. It basically said: Here is what eSNI needs to achieve in our opinion, we don't know how to do that
Between that point and when TLS 1.3 was published, several people brainstormed a proof of concept for how to actually make it work, which so far led to the draft you've linked.
The eSNI draft is defined as an extension to TLS 1.3 but - since the whole point is to deny snoopers information about who we're talking to - if we have to "fall back" to not doing eSNI because the server isn't compatible then we lost.
Cloudflare and Firefox devs cooperate to implement drafts of eSNI, so if you have a recent Firefox and a site which has opted into Cloudflare's trial of this feature, then it works for you, but the drafts definitely will change further and you should not go building anything based on this draft that you aren't able to support updating to future drafts or abandon altogether weeks or months from now.
> Cloudflare and Firefox devs cooperate to implement drafts of eSNI, so if you have a recent Firefox and a site which has opted into Cloudflare's trial of this feature, then it works for you, ...
Well, at least not yet with the latest release version of Firefox (v69). Tested with Cloudflare's own page for testing eSNI browser support (and TLS 1.3, DNSSEC & DoH). Firefox supports the other three but not eSNI, according to that page. Even the Dev channel (v71) has no support.
The link you posted is the right one, but it’s to the Internet-Draft. This is the step prior to becoming an RFC, where revisions are stored for everyone (including implementors) to use. So (for example) when you hear someone saying “I support TLS 1.3 Draft 8”, that means they support version 8 of the Internet-Draft.