Skip compression for range requests #446
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.
This PR fixes broken range requests when using the compression middleware by skipping response body compression when the
Content-Range
header is present in the response. It also strips theAccept-Ranges
response header when performing compression.Motivation
Fixes #416
Solution
I believe the correct behaviour for this library is to pass along the
Range
request header, and skip compression if theContent-Range
response header is present. This will allow range requests if the wrapped services support them, and skip compression in that circumstance to avoid corruption. If the user would rather compress everything, they can disallow range requests by stripping out theRange
request header in an earlier middleware.Notably, this is how a prominent Go library handles range requests and compression:
Content-Range
header is presentAccept-Ranges
header when compressing