Mirror server can promise a Content-Length the file no longer has

[xroche]

The mirror server stat'd a file, opened it, and sent the measurement as Content-Length. The engine rewrites index.html in place, so the stream could run dry early, and NanoHTTPD stops there with no padding and no error: the client waits for bytes that never arrive, and on a keep-alive connection it reads the next response as the tail of this one. Serving through NanoHTTPD's own newChunkedResponse removes the declared length, leaving nothing for the body to contradict, and the measuring helpers go with it. Non-text files lose their Content-Length in the trade; text/ and /json never had one, since NanoHTTPD gzips them whenever the client accepts it and chunks the result.

HEAD was broken in its own way. It keeps a stat'd length, because the chunked path prints Content-Length: -1 there instead. But NanoHTTPD's HEAD branch skips only the chunk framing, not the body write, so the reply carried the whole file after its headers, and the next request on that connection read those bytes as a status line. With Accept-Encoding: gzip, which is what a browser sends, it was a gzipped body under no length and no framing at all. HEAD now hands NanoHTTPD an empty stream under the real length and declines gzip, so it never opens the file it describes. The 404 and 403 replies return before any of that, so they were still writing a text body to a HEAD and desyncing the connection one request later. They answer with headers alone now, and a GET keeps its short message.

This does not close #130. The blank page comes from the engine rewriting index.html in place, and fixing that needs an atomic index write in the httrack repo. Chunked framing does not make a short read longer; it only stops the server claiming the file was complete. A browser never saw the old length on index.html because it accepts gzip, but wget and plain curl send no Accept-Encoding and did get one. The tests now drive a real loopback socket end to end and compare what arrives with the file; the truncation case reads one chunk before emptying it, so the rewrite lands mid-body by construction rather than by timing.

Refs #130