HTTP Compression not working for some files (JS and CSS)

[grv]

Hi Devs!!!

I see that we have enabled HTTP compression in in the HTTP and HTTPS connectors, but I am observing that it is not working properly for some of the JS and CSS files.

All medium to large files (more than 50 KB or so) are not getting compressed. Has anyone else observed the same? I can definitely see that Content-Encoding:gzip response header is set for all the files that are compressed and the transfer size does indicate they were compressed based on what size I see on the disk.


Thanks,
Girish Vasmatkar
HotWax Systems

[Michael Brohl-3]

Hi Girish,

how did you check that these files are not getting compressed before the
transfer?

They are decompressed by the browser after the transfer so you won't see
that they were compressed.

Regards,

Michael


Am 20.08.18 um 09:12 schrieb [hidden email]:

> Hi Devs!!!
>
> I see that we have enabled HTTP compression in in the HTTP and HTTPS connectors, but I am observing that it is not working properly for some of the JS and CSS files.
>
> All medium to large files (more than 50 KB or so) are not getting compressed. Has anyone else observed the same? I can definitely see that Content-Encoding:gzip response header is set for all the files that are compressed and the transfer size does indicate they were compressed based on what size I see on the disk.
>
>
> Thanks,
> Girish Vasmatkar
> HotWax Systems
>

[grv]

On 2018/08/20 07:20:38, Michael Brohl <[hidden email]> wrote:

> Hi Girish,
>
> how did you check that these files are not getting compressed before the
> transfer?
>
> They are decompressed by the browser after the transfer so you won't see
> that they were compressed.
>
> Regards,
>
> Michael
>
>
> Am 20.08.18 um 09:12 schrieb [hidden email]:
> > Hi Devs!!!
> >
> > I see that we have enabled HTTP compression in in the HTTP and HTTPS connectors, but I am observing that it is not working properly for some of the JS and CSS files.
> >
> > All medium to large files (more than 50 KB or so) are not getting compressed. Has anyone else observed the same? I can definitely see that Content-Encoding:gzip response header is set for all the files that are compressed and the transfer size does indicate they were compressed based on what size I see on the disk.
> >
> >
> > Thanks,
> > Girish Vasmatkar
> > HotWax Systems
> >
>
>
>

Hi Michael

I can see the response headers in Chrome developers tools. For some files for example, OfbizUtil.js, Content-Encoding:gzip indicating that it was compressed by the server and received in compressed format.
For the other ones, no Content-Encoding header is present. Also, there is a "Size" tab and a "Transferred" tab in FireBug showing 47.13 KB and 11.79 KB values respectively. For select2-4.0.6.js which is one of the one I don't see come compressed the corresponding values are 143.01 KB and 142.80 KB and the Content-Encoding header is also absent.

Thanks and Regards,
Girish Vasmatkar
HotWax Systems

[Scott Gray-3]

See the note under the compression config here:
https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Standard_Implementation

Regards
Scott


On 20 August 2018 at 07:38, [hidden email] <
[hidden email]> wrote:

>
>
> On 2018/08/20 07:20:38, Michael Brohl <[hidden email]> wrote:
> > Hi Girish,
> >
> > how did you check that these files are not getting compressed before the
> > transfer?
> >
> > They are decompressed by the browser after the transfer so you won't see
> > that they were compressed.
> >
> > Regards,
> >
> > Michael
> >
> >
> > Am 20.08.18 um 09:12 schrieb [hidden email]:
> > > Hi Devs!!!
> > >
> > > I see that we have enabled HTTP compression in in the HTTP and HTTPS
> connectors, but I am observing that it is not working properly for some of
> the JS and CSS files.
> > >
> > > All medium to large files (more than 50 KB or so) are not getting
> compressed. Has anyone else observed the same? I can definitely see that
> Content-Encoding:gzip response header is set for all the files that are
> compressed and the transfer size does indicate they were compressed based
> on what size I see on the disk.
> > >
> > >
> > > Thanks,
> > > Girish Vasmatkar
> > > HotWax Systems
> > >
> >
> >
> >
> Hi Michael
>
> I can see the response headers in Chrome developers tools. For some files
> for example, OfbizUtil.js, Content-Encoding:gzip indicating that it was
> compressed by the server and received in compressed format.
> For the other ones, no Content-Encoding header is present. Also, there is
> a "Size" tab and a "Transferred" tab in FireBug showing 47.13 KB and 11.79
> KB values respectively. For select2-4.0.6.js which is one of the one I
> don't see come compressed the corresponding values are 143.01 KB and 142.80
> KB and the Content-Encoding header is also absent.
>
> Thanks and Regards,
> Girish Vasmatkar
> HotWax Systems
>
>
>

[Michael Brohl-3]

Great, learned something new. Thank you Scott!

Reagrds,

Michael

Am 20.08.18 um 19:09 schrieb Scott Gray:

> See the note under the compression config here:
> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Standard_Implementation
>
> Regards
> Scott
>
>
> On 20 August 2018 at 07:38, [hidden email] <
> [hidden email]> wrote:
>
>>
>> On 2018/08/20 07:20:38, Michael Brohl <[hidden email]> wrote:
>>> Hi Girish,
>>>
>>> how did you check that these files are not getting compressed before the
>>> transfer?
>>>
>>> They are decompressed by the browser after the transfer so you won't see
>>> that they were compressed.
>>>
>>> Regards,
>>>
>>> Michael
>>>
>>>
>>> Am 20.08.18 um 09:12 schrieb [hidden email]:
>>>> Hi Devs!!!
>>>>
>>>> I see that we have enabled HTTP compression in in the HTTP and HTTPS
>> connectors, but I am observing that it is not working properly for some of
>> the JS and CSS files.
>>>> All medium to large files (more than 50 KB or so) are not getting
>> compressed. Has anyone else observed the same? I can definitely see that
>> Content-Encoding:gzip response header is set for all the files that are
>> compressed and the transfer size does indicate they were compressed based
>> on what size I see on the disk.
>>>>
>>>> Thanks,
>>>> Girish Vasmatkar
>>>> HotWax Systems
>>>>
>>>
>>>
>> Hi Michael
>>
>> I can see the response headers in Chrome developers tools. For some files
>> for example, OfbizUtil.js, Content-Encoding:gzip indicating that it was
>> compressed by the server and received in compressed format.
>> For the other ones, no Content-Encoding header is present. Also, there is
>> a "Size" tab and a "Transferred" tab in FireBug showing 47.13 KB and 11.79
>> KB values respectively. For select2-4.0.6.js which is one of the one I
>> don't see come compressed the corresponding values are 143.01 KB and 142.80
>> KB and the Content-Encoding header is also absent.
>>
>> Thanks and Regards,
>> Girish Vasmatkar
>> HotWax Systems
>>
>>
>>

[grv]

On 2018/08/20 17:09:35, Scott Gray <[hidden email]> wrote:

> See the note under the compression config here:
> https://tomcat.apache.org/tomcat-8.5-doc/config/http.html#Standard_Implementation
>
> Regards
> Scott
>
>
> On 20 August 2018 at 07:38, [hidden email] <
> [hidden email]> wrote:
>
> >
> >
> > On 2018/08/20 07:20:38, Michael Brohl <[hidden email]> wrote:
> > > Hi Girish,
> > >
> > > how did you check that these files are not getting compressed before the
> > > transfer?
> > >
> > > They are decompressed by the browser after the transfer so you won't see
> > > that they were compressed.
> > >
> > > Regards,
> > >
> > > Michael
> > >
> > >
> > > Am 20.08.18 um 09:12 schrieb [hidden email]:
> > > > Hi Devs!!!
> > > >
> > > > I see that we have enabled HTTP compression in in the HTTP and HTTPS
> > connectors, but I am observing that it is not working properly for some of
> > the JS and CSS files.
> > > >
> > > > All medium to large files (more than 50 KB or so) are not getting
> > compressed. Has anyone else observed the same? I can definitely see that
> > Content-Encoding:gzip response header is set for all the files that are
> > compressed and the transfer size does indicate they were compressed based
> > on what size I see on the disk.
> > > >
> > > >
> > > > Thanks,
> > > > Girish Vasmatkar
> > > > HotWax Systems
> > > >
> > >
> > >
> > >
> > Hi Michael
> >
> > I can see the response headers in Chrome developers tools. For some files
> > for example, OfbizUtil.js, Content-Encoding:gzip indicating that it was
> > compressed by the server and received in compressed format.
> > For the other ones, no Content-Encoding header is present. Also, there is
> > a "Size" tab and a "Transferred" tab in FireBug showing 47.13 KB and 11.79
> > KB values respectively. For select2-4.0.6.js which is one of the one I
> > don't see come compressed the corresponding values are 143.01 KB and 142.80
> > KB and the Content-Encoding header is also absent.
> >
> > Thanks and Regards,
> > Girish Vasmatkar
> > HotWax Systems
> >
> >
> >
>

Thanks Scot for the reply.

For what it is worth :
Figured that it is happening on Mac OS only and there is a nice explanation here ..
http://tomcat.10.x6.nabble.com/sendFiles-vs-compression-td5062656.html

Turns out that the decision to choose compression vs sendFile is based on that fact which connector is being used by Tomcat under the hood. sendFile is used to save CPU cycles if the file size is more that 48KB which was the case for all the files that appeared to not get compressed. sendFile will choose best strategy to send static files based on the underlying OS. That helps explain why it did not work in MacOS while it works for OFBiz instance deployed on Ubuntu.

I was having troubles with setting sendFile to false and I was using "off" as the value to turn it off.

The way to do it is under http-connector or any other connector for that matter.

<property name="useSendfile" value="false"/>

There is also some information on sendFile being broken on OS X...

https://blog.phusion.nl/2015/06/04/the-brokenness-of-the-sendfile-system-call/

Thanks and Best regards,
Girish Vasmatkar
HotWax Systems