On 2018/08/20 17:09:35, Scott Gray <scott.g...@hotwaxsystems.com> 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, girish.vasmat...@hotwaxsystems.com <
> girish.vasmat...@hotwaxsystems.com> wrote:
> 
> >
> >
> > On 2018/08/20 07:20:38, Michael Brohl <michael.br...@ecomify.de> 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 girish.vasmat...@hotwaxsystems.com:
> > > > 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


Reply via email to