Autopatch PATCH request response body frequently has incorrect content encoding

[betaprior]

I use Huma with the echo router via humaecho. I have echo gzip middleware enabled by default. This seems to not play well with autopatch, as follows: often, autopatch PATCH response unexpectedly comes through as gzipped when a plain text JSON is expected. This behavior was observed with a range of HTTP clients and a range of autopatched endpoints. The operation itself succeeds, returns 200, and performs the data changes expected, but the clients (expecting a JSON) barf on the binary response. A representative example from our API tests:

const response = await fetch('/test-endpoint', {
  method: 'PATCH',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ key: 'value' }),
});

const rawText = await response.clone().text();
console.log('Raw response:', rawText);  // supposed to be well-formed JSON but get binary gzipped data

Indeed, in autopatch.go, if you print the value of putWriter.Header().Get("Content-Encoding") you get gzip.

A way to work around it is to specify the "Accept-Encoding": "identity" header on the client side, however it seems that this is something that should not require additional headers. Because I don't understand the logic behind why the body comes through as gzipped in the case of autopatch and not with regular client-side GETs and PUTs, I am not sure what the correct fix is, but it would be nice to put it in place, or at the very least document that using a gzip middleware with autopatch requires the workaround above.

[danielgtaylor]

@betaprior thanks for reporting! I have not run into this, very interesting. I can definitely document it and will try to dig into the problem a bit to better understand it. Open to PRs if you want to submit one for the docs!