Recompute Content-Length on compression
#480
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Content-Lengthholds the number of bytes in an HTTP response after encoding and compression. Ourcompress_response()function breaks that: when the response it's compressing already includes aContent-Lengthheader, it may shorten the body but leave the header unchanged.I noticed this because of #465, since the textual error message proxied from Reddit gets compressed but already has
Content-Length. The issue is masked in normal operation because we don't compress the binary image data that Reddit is supposed to return. In debug builds, hyper catches the issue and panics, but in release builds we return a nonconformant HTTP response.Fix the issue by removing the header if we choose to compress, letting hyper compute the new value for us.