-
Bug
-
Resolution: Fixed
-
Low (View bug fix roadmap)
-
3.13
-
None
-
3.13
-
If you:
- Enable gzip compression in JIRA under General Configuration
- Send a SOAP request that accepts a compressed response
With the Accept-Encoding header:
$ wget -O - -S --header 'Accept-Encoding: gzip' http://localhost:8080/rpc/soap/jirasoapservice-v2?wsdl > /dev/null HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Encoding: Vary: Content-Type: text/xml;charset=utf-8 Date: Tue, 23 Sep 2008 02:27:31 GMT Connection: close
Without the Accept-Encoding header:
$ wget -O - -S http://localhost:8080/rpc/soap/jirasoapservice-v2?wsdl > /dev/null HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/xml;charset=utf-8 Date: Tue, 23 Sep 2008 02:31:45 GMT Connection: close
The problem is that some clients break while parsing the empty Content-Encoding, and such a header does not seem correct. Can please someone take a look at it, and report their findings?
[JRASERVER-15658] Empty Content-Encoding in SOAP requests when using gzip Accept-Encoding in request
This has been re-opened because atlassian-gzip is currently compiled against Java 1.5. JIRA 3.13.x targets Java 1.4.
We will need to make a 1.4 compatible version.
For customers that are "running JIRA 3.x" on Java 1.5 or better, the gzip jar mention on this issue should work.
Alan Berezin
added a comment - OK, I finally got it all working. I had to upgrade by mylyn plugins in addition to dropping in the new jar. So for me, this issue is resolved.
Alan Berezin
added a comment - OK, I finally got it all working. I had to upgrade by mylyn plugins in addition to dropping in the new jar. So for me, this issue is resolved. Alan,
Thanks for the update. I wonder why you are having problems. It's good to know - I'll ensure that we test with the mylyn client also when we test this fix. Can you confirm which version of Mylyn you are using?
Alan Berezin
added a comment - OK, at this point I am tentatively saying it doesnt work for me in the following sense. On the mylyn client, under the task respositoryies, I choose my JIRA connect, choose addl settings, choose 'compress'. The Compress option is what didnt work in the past. I assume it is the Compress option that forces the request to be a gzip request. After choosing that setting, i try to sync one task and it just hangs. Note that this behavior is different that the past failure mode wherein the client would give me a error dialog (something about a 301 error).
I am trying to packet sniff (using wireshark on linux) on the client side and seeing lots of wierdness :
- my sniffer isnt recognizing the packets as http so it is pain to pick though the data.
- seeing TCP Checksum errors. Ug!
If I do a
wget -O foo.txt -S --header 'Accept-Encoding: gzip' http://myserver:8080/rpc/soap/jirasoapservice-v2?wsdl > /dev/null
I do get the proper header
...
Content-Encoding: gzip
...
So, it seems like the new jar is doing its job correctly. I suspect that there is something else wrong on the client side.
Alan Berezin
added a comment - OK, at this point I am tentatively saying it doesnt work for me in the following sense. On the mylyn client, under the task respositoryies, I choose my JIRA connect, choose addl settings, choose 'compress'. The Compress option is what didnt work in the past. I assume it is the Compress option that forces the request to be a gzip request. After choosing that setting, i try to sync one task and it just hangs. Note that this behavior is different that the past failure mode wherein the client would give me a error dialog (something about a 301 error).
I am trying to packet sniff (using wireshark on linux) on the client side and seeing lots of wierdness :
my sniffer isnt recognizing the packets as http so it is pain to pick though the data.
seeing TCP Checksum errors. Ug!
If I do a
wget -O foo.txt -S --header 'Accept-Encoding: gzip' http://myserver:8080/rpc/soap/jirasoapservice-v2?wsdl > /dev/null
I do get the proper header
...
Content-Encoding: gzip
...
So, it seems like the new jar is doing its job correctly. I suspect that there is something else wrong on the client side. Alan,
I haven't fully tested that this works yet. If have already done it - let me know how it goes for you. Else I'll report back when I've made some progress.
The updated jar can be found here
The source (which is open source) can be found here
Alan Berezin
added a comment - Where can i get this latest atlassian-gzipfilter? I need to replace my 3.12.1#299 instance. I am having the same problem although i can use the mylyn plugin without compression.
Alan Berezin
added a comment - Where can i get this latest atlassian-gzipfilter? I need to replace my 3.12.1#299 instance. I am having the same problem although i can use the mylyn plugin without compression. As an added bonus - the WSDL that gets downloaded reduces from 220k to 12k. I don't know how much different it will make to normal SOAP requests, but it should make a difference to performance.
I have released atlassian-gzip 1.9 which is now Java 1.4 compatible.
It can be found here : https://maven.atlassian.com/public/com/atlassian/gzipfilter/atlassian-gzipfilter/1.9/atlassian-gzipfilter-1.9.jar
The source is here : https://svn.atlassian.com/svn/public/atlassian/atlassian-gzipfilter/tags/atlassian-gzipfilter-1.9/
Both 3.13.2 and 4.0 have been updated to use 1.9.
Existing JIRA users should be able to replace the atlassian-gzip jar they have with the 1.9.