Bug 844858 - tar.gz is turned off by default for JBoss
tar.gz is turned off by default for JBoss
Product: OpenShift Online
Classification: Red Hat
Component: Image (Show other bugs)
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Ben Parees
libra bugs
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2012-08-01 00:50 EDT by Steven Citron-Pousty
Modified: 2015-05-14 20:33 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-01-23 22:33:29 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steven Citron-Pousty 2012-08-01 00:50:05 EDT
Description of problem:
gzipping of content is one of the most recommended ways to improve web site performance. It also lowers the size of the network traffic from the server. There is a filter for JBoss that automatically compresses output if the browser says it can accept gzipped content.
Can we please turn it on by default. The JBoss team confirmed that there is no performance problems from this.

From the email thread:
On 07/16/2012 06:44 PM, Steven Citron-Pousty wrote:
Greetings Jean-Frederic:
Currently on OpenShift output is not being gzipped even when the browser tells the server it supports it. So there are two questions:
1) Developers want to turn this on for their jboss instance. What does that look like in the config file?

In the standalone.xml set the system property org.apache.coyote.http11.Http11Protocol.COMPRESSION to on like below:


       <property name="org.apache.coyote.http11.Http11Protocol.COMPRESSION" value="on"/>


2) Shouldn't we have this turned on by default for JBOSS since it is recommended best practice for web sites. If not, then why not?

It is not on by default in Apache httpd so we do the same. To get it in the Apache httpd you need to add something like
AddOutputFilterByType DEFLATE text/html
<files *.html>
SetOutputFilter DEFLATE



Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Bill DeCoste 2012-11-14 14:19:01 EST
I've updated the JBoss config
Comment 2 Jianwei Hou 2012-11-15 21:35:56 EST
Tested on devenv_2484

1. Ssh into instance, check jboss config has been updated according to fix.
Also check /etc/httpd/conf.d/jboss_compression.conf has enabled apache compression.
2. Create jboss applications
3. Access app's webset, check http headers, verify they are using gzip encoding:

<------------Request Headers------------>
If-Modified-Since:Fri, 16 Nov 2012 02:14:49 GMT
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4

<------------Response Headers------------>
Response Headersview source
Date:Fri, 16 Nov 2012 02:28:17 GMT
Via:1.0 file.rdu.redhat.com (squid/3.1.10)
X-Cache:HIT from file.rdu.redhat.com
X-Cache-Lookup:HIT from file.rdu.redhat.com:8080

I didn't find it using gzip encoding.
So I have added following in .openshift/config/standalone.xml and git push

       <property name="org.apache.coyote.http11.Http11Protocol.COMPRESSION" value="on"/>


This time, the response headers tells me my application is using gzip encoding.
<----------Response Headers----------->

According to comment 1, it's not turned on by default, have to turn it on by configuring standalone.xml manually, and there is also no fix for jbossews

So, assign this bug back, thanks!
Comment 3 Bill DeCoste 2012-11-19 12:33:13 EST
Updated standalone.xml
Comment 4 Jianwei Hou 2012-11-19 21:18:34 EST
Tested on devevn-stage_257

standalone.xml got updated for jbossas and jbosseap.

But I found this issue:

After a jbossas/jbosseap application is firstly created, accessing app's website, open development tool of chrome, refresh, the Response Headers does not indicate that it is using gzip encoding.

Like this:
<----------Response Headers----------->
Date:Tue, 20 Nov 2012 02:12:44 GMT
Keep-Alive:timeout=15, max=98

After git pushing this app, then access app's website again, the Response Headers shows that is is using gzip encoding.
Like this:
<----------Response Headers----------->
Date:Tue, 20 Nov 2012 02:05:40 GMT
Keep-Alive:timeout=15, max=100
Strict-Transport-Security:max-age=15768000, includeSubDomains

Actual result now is: gzip encoding for jbossas/jbosseap is enabled after first git push, so assign it back to see if we need further fix, thanks!
Comment 5 Ben Parees 2013-11-27 13:13:53 EST
I ran this test using jbossap-7 and it seems to be working:

1) rhc app create jbossapp jbossas-7
2) curl -v -H "Accept-Encoding:gzip,deflate,sdch" http://jbossapp-test.dev.rhcloud.com >& out
3) view "out" file:
Header is sent:
* About to connect() to jbossapp-test.dev.rhcloud.com port 80 (#0)
*   Trying
* Connected to jbossapp-test.dev.rhcloud.com ( port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: jbossapp-test.dev.rhcloud.com
> Accept: */*
> Accept-Encoding:gzip,deflate,sdch

Response is compressed:
< HTTP/1.1 200 OK
< Date: Wed, 27 Nov 2013 18:11:21 GMT
< Server: Apache-Coyote/1.1
< Accept-Ranges: bytes
< ETag: W/"41833-1385575868000"
< Last-Modified: Wed, 27 Nov 2013 18:11:08 GMT
< Content-Type: text/html; charset=UTF-8
< Content-Encoding: gzip
< Vary: Accept-Encoding,User-Agent
< ProxyTime: D=305089
< Transfer-Encoding: chunked

Can you confirm this is still not working? I think we can close this.
Comment 6 Meng Bo 2013-11-28 00:57:05 EST
Tested on devenv_4080,

Both jbossas and jbosseap can response with gzip encoding by default when request contains gzip encoding.

# curl -H "Accept-Encoding:gzip,deflate,sdch" -vI http://jbas1-bmengdev.dev.rhcloud.com
> Accept-Encoding:gzip,deflate,sdch
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Content-Encoding: gzip

# curl -H "Accept-Encoding:gzip,deflate,sdch" -vI http://jbeap1-bmengdev.dev.rhcloud.com
> Accept-Encoding:gzip,deflate,sdch
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Content-Encoding: gzip

Note You need to log in before you can comment on or make changes to this bug.