Add support for gzip compression in API calls - #198
Merged
Conversation
Owner
|
Good idea. This seems generic enough, any plan to integrate it into libpurple util_fetch calls? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There's currently a 4MiB limit on all API responses (4096*1024 in the
purple_util_fetch_url_request_len_with_account()call ofslack-api.c) so potentially could cause errors when making API requests with a >4MiB response - eg see issue #81 which had a workaround for large responses by paginating by 500 users at a time.Adding gzip compression can help with large responses from the server and preventing the buffer from overflowing and corrupting. Fortunately, json gzip compresses really well, eg a
/api/users.listAPI response I had which was 497KiB, compressed down to a 42KiB gzipped response.This PR adds gzip content-encoding support to help reduce network bandwidth and allow for larger responses before there's json parser corruption.