Self-Contained Pure-Go Web Server with Lua, MD, HTTP/2, QUIC, Redis Support (opens in new tab)

Correct, the NGINX configuration should be something like:

    gzip on;
    gunzip on;
    gzip_http_version 1.1;
    gzip_proxied any;
    gzip_comp_level 5;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_min_length 2048;

Compression technologies, including gzip, obviously have the goal of making things smaller by predicting later data based on earlier data. If the later data looks more like the earlier data, the result is smaller than if it was random gibberish. Compression!

If an attacker controls /some/ of this data, and would like to read /other parts/, they can abuse compression to measure whether the parts they don't know are "like" the part they control, because if they are then the compression will make the results shorter than otherwise which they can passively measure.

It's not a problem to move a compressed object over a secure channel on its own, the problem arises if either you try to compress the channel which is moving objects from different origins (e.g. a cookie set by a random advertising web site and your Facebook password) or compress a composite object e.g. maybe your backups mixed with a file you downloaded from a dodgy "pirate" video site.

In scenario when an attacker can see encrypted message (e.g. monitoring network traffic) and can affect part of the message that is being encrypted, he can use the compression to his advantage. He can for example try different inputs and observe the length of encrypted message, if with the certain input the length drops that means the given input contains string that's similar to another part of the decrypted message and the compressing algorithm did its job and used that to reduce the size.

This was mentioned in 2012 when CRIME[1] (also included BEAST[2] exploit) and later BREACH[2] vulnerability (when it was considered cool to come up with cool sounding name, creating a logo and a website for specific vulnerabilities)

[1] https://en.wikipedia.org/wiki/CRIME

[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST...

[3] https://en.wikipedia.org/wiki/BREACH

This shouldn't be true in any sane system.

I don't see anything like that documented for apache's mod_deflate/zlib.

Makes more sense to use the verb "negotiating" with Accept-* headers rather than "honoring".

This makes obvious sense once you consider that the client tells the server which compression formats it supports in every request yet not every data format is compressible, nor does the server necessary support any candidate compression format.

For example, the server wouldn't gzip a jpeg since it's already compressed.

All Accept-* headers are like this. e.g. the server doesn't necessarily support any of the languages requested in the Accept-Language header, but it doesn't hurt to ask. You always have to inspect the response headers to see the result of negotiation.

"Accept-Encoding" means only that the client also understands specific encoding (in this case compression) it is still up to the server to chose what to dot. There was a time when browsers didn't support any compression. This header was introduced to signal to server what is acceptable by the client, that's why the header allows specifying multiple compression algorithms.

Similar thing is with header that's quite useful, but for some reason very few sites honor it: "Accept-Language" browser can specify which languages are preferred, but it is up to server to honor it (for example given language version is not available).

Applications that always know exactly what they want to send disable this algorithm, as that article explains, by setting TCP_NODELAY or its moral equvialents in their framework. A web server will almost invariably set TCP_NODELAY.

More sophisticated algorithms can either decide exactly which packets to send, or use TCP_CORK to shove part of a packet into a buffer before they add the rest of the stuff, e.g. preparing HTTP headers and then adding the static document that goes after them.

If you read the page you linked, it says the algorithm applies to data of any size.

Yes, also compressing and decompressing a small amount of bytes may take longer than just sending it uncompressed.

You have it backwards, apache or nginx size is not for the novelty. Go is just a pig and its size grows every new release, and the size isn't really for being statically linked or debugging symbols, because it's huge even when those options are disabled.

Right now a "hello world" application in Go has comparable size to an OS with full GUI.

My Apache installation with modules takes 4.3MB, and I'm quite sure Apache with modules can do more than Algernon.

Very civilized comment from mr. Caddy himself. Heartening, not least considering the kind of vendettas some projects - Caddy among them - have to put up with from competing developers.

Well yeah it's definitely an interesting approach. I guess it's much more lean than running a whole Ubuntu container VM that has all of these things installed, or running a gigantic bloated Javascript toolchain just to convert the scss or md files to css or html.

As someone else commented, the huge size of Go executables is down to a design decision to include a map of functions for panic reporting. There was a whole discussion on this recently on HN.

I don't know why the grandparent was downvoted. Go binaries are not small and the claim that this is a "small" single executable is untrue.

Hopefully the Go team will give us a flag to decide for ourselves whether to optimise for executable size or initialisation time. I know I'm fed up of uploading 50Mb files over dodgy wifi+vpn connections to update my server.

(edit fix repetition of design)

I don't have nginx installed (got the number from a web download of the .deb package), but running this for apache:

$ echo $((`ldd /usr/sbin/apache2 | cut -d">" -f 2 | sed "s/(.*$//;s/ //" | xargs du -L | cut -f 1 | sed "s/$/+/" | xargs echo` 0))

3200

So 3.2 MB of shared library dependencies. 1.8 MB just being the libc which is almost guaranteed to be used by a different program already.

On my FreeBSD machine, all files in the entire apache package (including modules, manpages, headers, default pages, graphic for displaying directories in gif and png formats, tools are) take 4.3MB

I'd love to help, but my coding time is already taken building a product.

I pretty much followed the instructions here: https://godoc.org/golang.org/x/crypto/acme/autocert

edit, better here: https://blog.kowalczyk.info/article/Jl3G/https-for-free-in-g...

I didn't believe it could be that simple, but it worked first time and has proven really robust.