go-pkgz / rest / 32197883937

97%

push

github

Negotiate gzip on the response content type (#51)

* fix: negotiate gzip on the response content type

Previously the middleware picked compression from the request Content-Type,
which a normal GET does not send, so it fell back to application/octet-stream
and skipped compression for exactly the JSON and HTML responses it exists to
compress. A request that did carry a matching type could equally get an
unrelated binary response compressed. The old tests set a request Content-Type,
which is why they passed.

The decision now waits until the response content type is known, taken from the
handler's header or sniffed from the first chunk when it set none. Along the
way: Accept-Encoding is parsed so gzip;q=0 is honoured, bodyless 204 and 304
responses are left alone, Content-Length is dropped only when the body is
actually compressed, and Flush, Hijack and Unwrap pass through so streaming and
protocol upgrades keep working.

* docs: describe gzip response-based negotiation

* fix: tighten when the gzip writer compresses and how it commits

Six defects in the new writer, each with a test that fails without the fix:

Flush before the first write committed the headers while the compression
decision was still open, so a later textual write went out gzipped under
identity headers. The decision is now settled before the headers leave.

A panicking handler was committed as 200 by the deferred close, which left an
outer Recoverer unable to replace it with a 500. An uncommitted response is now
left alone when the handler did not return normally.

A response the handler had already encoded was compressed again and relabelled
gzip, and a 206 was compressed although its Content-Range offsets describe the
uncompressed representation. Both are skipped now.

WriteHeader let a second call replace the status when the first could not commit
for want of a content type, where net/http keeps the first. Interim 1xx
responses pass straight through, so Early Hints no longer becom... (continued)

135 of 137 new or added lines in 1 file covered. (98.54%)

1633 of 1675 relevant lines covered (97.49%)

47.63 hits per line