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 the Accept-Ranges response header when performing compression.
I believe the correct behaviour for this library is to pass along the Range request header, and skip compression if the Content-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 the Range request header in an earlier middleware.
Notably, this is how a prominent Go library handles range requests and compression:
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 https://github.com/tower-rs/tower-http/issues/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