You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
betaprior
changed the title
Autopatch PATCH request response body is frequently corrupted
Autopatch PATCH request response body frequently has incorrect content encoding
Mar 9, 2025
@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!
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:Indeed, in autopatch.go, if you print the value of
putWriter.Header().Get("Content-Encoding")
you getgzip
.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.The text was updated successfully, but these errors were encountered: