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

[All languages] Support for gzip compression #3365

Open
michaelkourlas opened this issue Jul 13, 2016 · 3 comments
Open

[All languages] Support for gzip compression #3365

michaelkourlas opened this issue Jul 13, 2016 · 3 comments

Comments

@michaelkourlas
Copy link
Contributor

Description

This is a feature request for two options enabling support for gzip compression for the generated API clients for all languages.

The first option would enable support for compression in API requests. When this option is turned on, the client would:

  1. Add Content-Encoding: gzip to the HTTP request headers
  2. Compress the HTTP request bodies using gzip

The second option would enable support for compression in API responses. When this option is turned on, the client would:

  1. Add Accept-Encoding: gzip to the HTTP request headers
  2. Decompress the bodies of HTTP responses with a response header of Content-Encoding: gzip

Ideally, both options would be on by default.

Related issues

#3279 discusses how to add gzip support to the Java API.

Suggest a Fix

For some languages, this won't be possible. For example, the JavaScript API presumably uses XmlHttpRequest behind the scenes when running in the browser, and the spec won't let you set encoding-related headers.

For other languages, though, this should be fairly straightforward. For example, in Java, adding support for GZIP compression for API requests and responses in the Jersey 1.x client consists of simply adding:

client.addFilter(new GZIPContentEncodingFilter());

to the rebuildHttpClient function in ApiClient.java. Passing in the parameter false to the constructor would enable it only for responses. Simply encapsulate this behaviour behind a couple of properties and you're done!

@wing328 wing328 modified the milestones: v2.2.0, v2.3.0 Jul 19, 2016
@wing328
Copy link
Contributor

wing328 commented Jul 20, 2016

I saw your proposal in OAI/OpenAPI-Specification#738

For the time being, we can use x-content-encoding (in the same level as consumes, produces)

To support it, it comes down to the HTTP libraries used in the API clients (whether it has a switch/flag to easily support gzip or other content encodings).

@wing328 wing328 modified the milestones: v2.2.1, v2.2.2, Future Aug 8, 2016
@jfiala
Copy link
Contributor

jfiala commented Oct 16, 2016

added gzip support for both the jaxrs-cxf (server) and to the jaxrs-cxf client in PR #4003 + documented the supported gzip feature using interface GzipFeatures.

@chenditc
Copy link

chenditc commented Nov 3, 2016

It would be very helpful for the client using mobiles. Saving mobile data and increase speed can improve UX a lot.

wing328 pushed a commit that referenced this issue Mar 8, 2017
* Fix for issue 3365 for Java

* Added tests

* Convert CRLF to LF

* Convert CRLF to LF in tests
spr3nk3ls pushed a commit to spr3nk3ls/swagger-codegen that referenced this issue Mar 28, 2017
…wagger-api#4967)

* Fix for issue 3365 for Java

* Added tests

* Convert CRLF to LF

* Convert CRLF to LF in tests
mguan-trulia added a commit to mguan-trulia/swagger-codegen that referenced this issue May 2, 2017
mguan-trulia added a commit to mguan-trulia/swagger-codegen that referenced this issue May 2, 2017
davidgri pushed a commit to davidgri/swagger-codegen that referenced this issue May 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants