After some experimentation, I found that the sendfile(2) support did not
really save any time compared to just write(2) from an already
memory-mapped file.
After some reading, I think open/sendfile is supposed to be slightly
more efficient than open/mmap/write — but if we already did the mmap
step, then it doesn't save us much.
Moreover, the code to support sendfile(2) is a bit icky, and also forces
us to close the HTTP connection after serving a file.
Sometimes we might be asked to serve up a zero-length input file,
typically from some machine-generated CSS etc. We make some very
rudimentary guess about the content-type the caller wanted and skip the
mmap(2) call.
Since packing can be quite slow, it is nice to display progress to the
caller. We use the excellent github.com/vbauerster/mpb library to do so,
and add a bit of colour with github.com/logrusru/aurora.
Finally, augment the inspector and packer with a summary printer that
displays the overall file size/count, and compression ratio for each
compression type.
We now support single part ranges, as per:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests#Single_part_ranges
Multi-part ranges are not implemented because there have been far too
many bugs in this area.
It interacts with compression by selecting a byte range from the
compressed stream. Since the compressed stream is fixed, the results are
consistent.
If a .svg file doesn't have a “<?xml…” prolog, then it would be detected as plain
text. Allow extension-based override of the content-type in this case.
Having done a bit more research on exactly how to use sendfile()
effectively with Go's own event loop, we can now leave the HTTP socket
in non-blocking mode and correctly integrate with the event loop to wait
for the socket to be writeable once more.
Rather than setting "Cache-Control: no-store", use "no-cache". The
difference is that "no-store" tells the browser that it must always
completely re-fetch the resource; whereas "no-cache" means that the
browser can write the resource to disk but must re-validate it (e.g.
using Etags) before re-using it.
Laurence Withers