4.0 GenericApiGWTService responses no longer being gzipped.
Hi, While I was the network traffic in my browser for an issue I was working on. I noticed the response sizes being unusually large. When I compared it against a similar sized 3.6 installation the response was huge. Checking the headers it appears that the response no longer is gzipped before being send to the user. Does anyone know of any changes to that recently? I am unsure of what exactly gzipped the responses to begin with. I was assuming either a filter or some jboss setting. If anyone could shed some light on this it would be appreciated. Thanks, Alexander
On 01/04/2016 11:01 PM, Alexander Wels wrote:
Hi,
While I was the network traffic in my browser for an issue I was working on. I noticed the response sizes being unusually large. When I compared it against a similar sized 3.6 installation the response was huge. Checking the headers it appears that the response no longer is gzipped before being send to the user. Does anyone know of any changes to that recently? I am unsure of what exactly gzipped the responses to begin with. I was assuming either a filter or some jboss setting.
If anyone could shed some light on this it would be appreciated.
Thanks, Alexander
The gzip configuration is in two places: 1. In the configuration of the web server subsystem of the application server. When using JBoss EAP the web subsystem is Tomcat, and gzip is implemented using a valve, configured here: https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-e... When using WildFly the web subsystem is Undertow, and gzip is implemented using a filter, configured here: https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-e... These two places only make sense when using the HTTP connectors, as the AJP connector doesn't support compression. This is what is used in development environments. 2. In the configuration of the Apache web server, using an output filter configured here: https://github.com/oVirt/ovirt-engine/blob/master/packaging/conf/ovirt-engin... The setup application puts the contents of this template inside /etc/httpd/conf.d/z-ovirt-engine-proxy.conf. This is what is used in production environments, where Apache is used as the web frontend. I'm not aware of any recent change to these configurations. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
On Tuesday, January 05, 2016 12:56:31 AM Juan Hernández wrote:
On 01/04/2016 11:01 PM, Alexander Wels wrote:
Hi,
While I was the network traffic in my browser for an issue I was working on. I noticed the response sizes being unusually large. When I compared it against a similar sized 3.6 installation the response was huge. Checking the headers it appears that the response no longer is gzipped before being send to the user. Does anyone know of any changes to that recently? I am unsure of what exactly gzipped the responses to begin with. I was assuming either a filter or some jboss setting.
If anyone could shed some light on this it would be appreciated.
Thanks, Alexander
The gzip configuration is in two places:
1. In the configuration of the web server subsystem of the application server. When using JBoss EAP the web subsystem is Tomcat, and gzip is implemented using a valve, configured here:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-e ngine/ovirt-engine.xml.in#L51
When using WildFly the web subsystem is Undertow, and gzip is implemented using a filter, configured here:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-e ngine/ovirt-engine.xml.in#L565
Juan, So looking at the regex for matching the filter it matches on text/(json/html/javascript/json) or application/(json/xml) for the content- type. Looking at the request headers the request is made with text/x-gwt-rpc. Thus not matching the regex, and thus the response is not compressed. So it appears the content-type header changed instead of the valve/filter. I will see if I can find out why that changed. Depending on the result we might have to adjust the filter to include text/x-gwt-rpc.
These two places only make sense when using the HTTP connectors, as the AJP connector doesn't support compression. This is what is used in development environments.
2. In the configuration of the Apache web server, using an output filter configured here:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/conf/ovirt-engin e-proxy.conf.v2.in#L37
The setup application puts the contents of this template inside /etc/httpd/conf.d/z-ovirt-engine-proxy.conf.
This is what is used in production environments, where Apache is used as the web frontend.
I'm not aware of any recent change to these configurations.
On Tuesday, January 05, 2016 09:42:38 AM Alexander Wels wrote:
On Tuesday, January 05, 2016 12:56:31 AM Juan Hernández wrote:
On 01/04/2016 11:01 PM, Alexander Wels wrote:
Hi,
While I was the network traffic in my browser for an issue I was working on. I noticed the response sizes being unusually large. When I compared it against a similar sized 3.6 installation the response was huge. Checking the headers it appears that the response no longer is gzipped before being send to the user. Does anyone know of any changes to that recently? I am unsure of what exactly gzipped the responses to begin with. I was assuming either a filter or some jboss setting.
If anyone could shed some light on this it would be appreciated.
Thanks, Alexander
The gzip configuration is in two places:
1. In the configuration of the web server subsystem of the application server. When using JBoss EAP the web subsystem is Tomcat, and gzip is implemented using a valve, configured here:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt -e ngine/ovirt-engine.xml.in#L51
When using WildFly the web subsystem is Undertow, and gzip is implemented using a filter, configured here:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt -e ngine/ovirt-engine.xml.in#L565
Juan,
So looking at the regex for matching the filter it matches on text/(json/html/javascript/json) or application/(json/xml) for the content- type. Looking at the request headers the request is made with text/x-gwt-rpc. Thus not matching the regex, and thus the response is not compressed. So it appears the content-type header changed instead of the valve/filter. I will see if I can find out why that changed. Depending on the result we might have to adjust the filter to include text/x-gwt-rpc.
So the content-type has been x-gwt-rpc for a long time now, since GWT 1.5. So I don't understand why it suddenly stopped working. If I change the filter to be the following it works. I will create a patch for it. <host name="default-host" alias="localhost"> <filter-ref name="gzip" predicate='regex[pattern="(text/(css|html|javascript|json| xml|x-gwt-rpc))|(application/(json|xml))(;\w?charset\w?=\w?UTF-8)?", value=%{o,content-type}, full-match=true]'/> </host>
These two places only make sense when using the HTTP connectors, as the AJP connector doesn't support compression. This is what is used in development environments.
2. In the configuration of the Apache web server, using an output filter configured here:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/conf/ovirt-eng in e-proxy.conf.v2.in#L37
The setup application puts the contents of this template inside /etc/httpd/conf.d/z-ovirt-engine-proxy.conf.
This is what is used in production environments, where Apache is used as the web frontend.
I'm not aware of any recent change to these configurations.
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
participants (2)
-
Alexander Wels -
Juan Hernández