Friscia, Michael michael.friscia at yale.edu
Fri Aug 24 10:56:00 UTC 2018

Thank you for that explanation. I'm still debugging this with our CDN vendor. They have identified a number of bugs on their end which explain the odd behavior I've been seeing. 

Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
(203) 931-5381 - mobile
http://web.yale.edu <http://web.yale.edu/>

On 8/23/18, 2:00 PM, "nginx on behalf of Maxim Dounin" <nginx-bounces at nginx.org on behalf of mdounin at mdounin.ru> wrote:

    On Thu, Aug 23, 2018 at 11:21:02AM +0000, Friscia, Michael wrote:
    > What would be the reason that setting
    > Gzip_types *;
    > Is bad?
    Usually there are responses which are not compressible, so trying 
    to gzip them is just a waste of resources.  Also there can be 
    cases when the client announces gzip support, but in fact have 
    problems when some types of responses are compressed - for 
    example, there were problems with compressed javascripts in some 
    browsers in the past.
    If you are sure that in a particular configuration all possible 
    responses must be gzipped, "gzip_types *;" should be fine.  You 
    may want to limit it to a particular location or server though.
    > I’m running into a compression problem and if I set it to * 
    > everything gzips just fine but if I list them out explicitly the 
    > type image/jpeg is not being gzip’d via proxy request but all 
    > others are gzip’d by proxy. Gzip_proxied is set to any.
    As long as Content-Type of the response is "image/jpeg", there 
    should be not difference between "gzip_types *" and "gzip_types 
    image/jpeg ...".  If you see a difference, please provide more 
    details - full configuration and a debug log would be ideal.
    Maxim Dounin
    nginx mailing list
    nginx at nginx.org

More information about the nginx mailing list