Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump the API version to pick up license lines. #1995

Merged
merged 1 commit into from
Nov 2, 2017

Conversation

tschroed
Copy link
Contributor

@tschroed tschroed commented Nov 2, 2017

Signed-off-by: Trevor Schroeder trevors@google.com

Signed-off-by: Trevor Schroeder <trevors@google.com>
@mattklein123 mattklein123 merged commit f64dd4f into envoyproxy:master Nov 2, 2017
jpsim added a commit that referenced this pull request Nov 28, 2022
Commit Message: Decompress even when `no-transform` is specified
Additional Description: This leverages the flag added in #19399 to always decompress responses, regardless of the presence of a `no-transform` cache control header, matching the more lenient behavior of other client-side networking libraries such as OkHttp or URLSession, especially in cases where the remote server is not under the client developer's control.
Risk Level: Low, responses that would previously fail to decode will now succeed when a compressed response comes with a `no-transform` cache control header.
Testing: Added unit tests in Envoy and manually confirmed in an Android app that gzipped responses with `no-transform` that previously failed now succeed.
Docs Changes: Not needed.
Release Notes: Added.
Platform Specific Features: This is configured to apply regardless of the platform, so both iOS & Android will get this new behavior.

Signed-off-by: JP Simard <jp@jpsim.com>
jpsim added a commit that referenced this pull request Nov 29, 2022
Commit Message: Decompress even when `no-transform` is specified
Additional Description: This leverages the flag added in #19399 to always decompress responses, regardless of the presence of a `no-transform` cache control header, matching the more lenient behavior of other client-side networking libraries such as OkHttp or URLSession, especially in cases where the remote server is not under the client developer's control.
Risk Level: Low, responses that would previously fail to decode will now succeed when a compressed response comes with a `no-transform` cache control header.
Testing: Added unit tests in Envoy and manually confirmed in an Android app that gzipped responses with `no-transform` that previously failed now succeed.
Docs Changes: Not needed.
Release Notes: Added.
Platform Specific Features: This is configured to apply regardless of the platform, so both iOS & Android will get this new behavior.

Signed-off-by: JP Simard <jp@jpsim.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants