[ovirt-devel] 4.0 GenericApiGWTService responses no longer being gzipped.
Alexander Wels
awels at redhat.com
Tue Jan 5 14:42:38 UTC 2016
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.
More information about the Devel
mailing list