Details
-
Bug
-
Resolution: Fixed
-
Medium
-
5.0
-
eac/j, jira.atlassian.com
-
5
-
Description
The "Accept-Encoding: gzip" header seems to be ignored by the new JIRA REST API.
This is quite important for reducing network traffic, especially because most of the RESPONSE data is highly compressible.
For example, I would expect the following request to return a gzipped response:
curl -v -H "Accept-Encoding: gzip" -u admin:admin http://localhost:2990/jira/rest/api/2/issue/createmeta
Instead, I am returned raw, uncompressed JSON.
$ curl -v -H "Accept-Encoding: gzip" -u admin:admin http://localhost:2990/jira/rest/api/2/issue/createmeta * About to connect() to localhost port 2990 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 2990 (#0) * Server auth using Basic with user 'admin' > GET /jira/rest/api/2/issue/createmeta HTTP/1.1 > Authorization: Basic YWRtaW46YWRtaW4= > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 > Host: localhost:2990 > Accept: */* > Accept-Encoding: gzip > < HTTP/1.1 200 OK < Server: Apache-Coyote/1.1 < X-AREQUESTID: 1019x44x1 < Set-Cookie: JSESSIONID=4FC8743C9332536F139451F535178661; Path=/ < X-Seraph-LoginReason: OK < Set-Cookie: atlassian.xsrf.token=BP8Q-WXN6-SKX3-NB5M|a9125d71af8b9213c0e818e0a708d6a8b10d6008|lin; Path=/jira < X-AUSERNAME: admin < Cache-Control: no-cache, no-store, no-transform < Content-Type: application/json;charset=UTF-8 < Transfer-Encoding: chunked < Date: Sun, 04 Mar 2012 05:59:18 GMT < * Connection #0 to host localhost left intact * Closing connection #0 {"expand":"projects","projects":[{"self":"http://localhost:2990/jira/rest/api/2/project/NERDS","id":"10000","key":"NERDS","name":"Angry Nerds","avatarUrls":{"16x16":"http://localhost:2990/jira/secure/projectavatar?size=small&pid=10000&avatarId=10011","48x48":"http://localhost:2990/jira/secure/projectavatar?pid=10000&avatarId=10011"},"issuetypes":[{"self":"http://localhost:2990/jira/rest/api/2/issuetype/1","id":"1","description":"A problem which impairs or prevents the functions of the product.","iconUrl":"http://localhost:2990/jira/images/icons/bug.gif","name":"Bug","subtask":false},{"self":"http://localhost:2990/jira/rest/api/2/issuetype/2","id":"2","description":"A new feature of the product, which has yet to be developed.","iconUrl":"http://localhost:2990/jira/images/icons/newfeature.gif","name":"New Feature","subtask":false},{"self":"http://localhost:2990/jira/rest/api/2/issuetype/3","id":"3","description":"A task that needs to be done.","iconUrl":"http://localhost:2990/jira/images/icons/task.gif","name":"Task","subtask":false},{"self":"http://localhost:2990/jira/rest/api/2/issuetype/4","id":"4","description":"An improvement or enhancement to an existing feature or task.","iconUrl":"http://localhost:2990/jira/images/icons/improvement.gif","name":"Improvement","subtask":false},{"self":"http://localhost:2990/jira/rest/api/2/issuetype/5","id":"5","description":"The sub-task of the issue","iconUrl": ....
I would expect to see a Content-Encoding: gzip header in the response.
The "use gzip compression" option in JIRA is turned ON.
The good news? There is a simple fix for this.
Ideally in Atlassian REST, however you can also do this in JIRA, add the following to the request before the response is set to the client.
// this ensures application/json is gzipped! see UrlRewriteGzipCompatibilitySelector // a typical response here is 3x smaller with compression enabled. request.setAttribute("gzipMimeTypes", MediaType.APPLICATION_JSON);