gzip compression wildcards *STILL* not working

Discussion in 'Bug Reports' started by aww, Jul 23, 2007.

  1. aww

    aww Well-Known Member

    I reported this back with 3.1 and it's still not working in 3.2


    text/* is NOT being obeyed

    For example I discovered text/javascript was not being compressed and I had to add it manually, in addtion to text/*

    But now I am having an additional problem in that .htc files which are mime type "text/x-component" do not get compressed even when text/x-component is added to the list. The analyzer I use to determine this shows the proper mime type is being sent and will always accept compression if the server offers it. The filesize is larger than the minimum set for compression.
    Last edited: Jul 23, 2007
  2. mistwang

    mistwang LiteSpeed Staff

    You need to add those types to LiteSpeed's MIME configuration file through our web admin interface.
  3. aww

    aww Well-Known Member

    Sorry if I am not being clear, but I did indeed add them through the admin interface and did the graceful restart.

    Wildcards still do not work.

    Please test the standard version in your lab and confirm?
  4. mistwang

    mistwang LiteSpeed Staff

    Are you sure. It should be added to the server wide MIME configuration, vhost level or context level does not work.
  5. aww

    aww Well-Known Member

    I posted the url to show you the menu that it's under.
    It's under tuning.

  6. xing

    xing LiteSpeed Staff

    No, it should be under Server->General->MIME File, add your MIME there
  7. aww

    aww Well-Known Member

    litespeed supports the "addtype" directive and I've done it in .htaccess for backwards compatibility with apache

    If it's added by addtype, shouldn't the gzip compression be enforced if the mime is in litespeeds compression list? That would mimic apache's mod_gzip behavior/directives.
  8. mistwang

    mistwang LiteSpeed Staff

    Type added through AddType is not checked for compression. Only globally defined types are. It does not hurt anything by adding the type globally.
    We will address this issue later.
  9. aww

    aww Well-Known Member

    Ah, so technically it is a bug, since it doesn't mimic apache's compatibility. At least I know now that I'm not going crazy and know what's causing this.

    Optionally, in a future version you might want to consider supporting mod_gzip directives in httpd.conf/htaccess?

    Here's a list of them with definitions:
    Litespeed already has control over almost all those options so technically you could mimic it if you wanted.
  10. subBlue

    subBlue Active Member

    YSlow for profiling in Firebug and GZip

    I've been using the new YSlow addon for performance profiling in Firebug.

    None of the CSS or JS files served by my site are getting gzipped despite having the default settings of text/*, application/x-javascript, application/xml in the list of compressible types. I also tried adding text/css directly to the list but it still wouldn't compress the CSS.

    The header settings for the CSS files are defined as text/css and that is listed in the recognised mime-types in LS, so I don't know why the CSS isn't getting compressed. The main page body is getting compressed though.

    The site is a Rails app running with LS 3.2-ent, but we are seeing this behaviour with all four of our servers using LS, which have pretty much the default configuration settings. Any suggestions here?
  11. aww

    aww Well-Known Member

    Argh, you are correct. text/css is not compressing either and I could have sworn I checked for and fixed this in our 3.1.1 configuration. So it either reverted or never worked. That's millions of pageviews now without compression :(

    And that one *is* under "Mime Type Definition" by default.

    So it's definitely a bug unless they can explain otherwise?

    I assume you are using the commercial version given the number of servers, etc. so this is not just a standard version bug anymore...

    added: even when the file is renamed to style.txt and served as text/plain it's not compressed

    added: even the css on this site is not being compressed:

    refuses to be served with compression
    (and I am assuming litespeed has text/* in their compresion settings and text/css in their default mime types)

    Last edited: Jul 27, 2007
  12. mistwang

    mistwang LiteSpeed Staff

    We will look into the problem.
  13. mistwang

    mistwang LiteSpeed Staff

    The problem should be addressed in the latest 3.2.1 build. A dedicate gzip cache directory will be used for static content, so LSWS will not require rewrite permission to user's document root directory in order to serve compressed version of static files.
  14. aww

    aww Well-Known Member

    Wonderful news. Will be testing shortly.

    By the way, I wanted to report (again) that I've always had trouble doing a direct wget from your servers of the package. The download stalls out. To solve the problem I have to limit the rate (and even that doesn't always work)

    wget --limit-rate=100000 http://www.litespeedtech.com/packages/3.0/lsws-3.2.1-std-i386-linux.tar.gz
  15. aww

    aww Well-Known Member

    Apparently I will have to wait for more instructions.
    Upgraded to 3.2.1 and I see the new "Static GZIP Cache Directory" setting.

    I tried /tmp and /tmp/ and $SERVER_ROOT/gzip/
    Nothing worked (restarted lsws after each time)
    Still no compression on .css and .js types.

    There are now files however in the $SERVER_ROOT/gzip directory and the owner has been changed from root:root to nobody:nobody so I believe lsws sees it and is using it.

    Both the .css and .js files I am testing on are well above the minimum filesize for compression.

    I'll wait to hear more...
    Last edited: Aug 7, 2007
  16. mistwang

    mistwang LiteSpeed Staff

    The MIME type of .js is not text/*, so you need to add that explicitly.
    If the file is cache, then the response header will not include the gzip header. Clear your browser cache and try again.
  17. aww

    aww Well-Known Member

    I added the mime type for js long ago.
    But let's just use the css for now as an example.

    Both my browser and my php test tool for gzip (which does not cache in any circumstance) are showing it as still uncompressed.

    GET /forums/example/style.css HTTP/1.1
    Host: example.com
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20060909 Firefox/
    Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    Pragma: no-cache
    Cache-Control: no-cache
    HTTP/1.x 200 OK
    Date: Wed, 08 Aug 2007 14:19:40 GMT
    Server: LiteSpeed
    Accept-Ranges: bytes
    Connection: Keep-Alive
    Keep-Alive: timeout=5, max=100
    Cache-Control: max-age=604800
    Expires: Wed, 15 Aug 2007 14:19:40 GMT
    Etag: "1dde-46aca652-37c334e"
    Last-Modified: Sun, 29 Jul 2007 14:38:10 GMT
    Content-Type: text/css
    Content-Length: 7646
    Last edited: Aug 8, 2007
  18. mistwang

    mistwang LiteSpeed Staff

    Please try adding "text/css" explicitly to the list see if help, we have done some experiments with our live site, sometime it interfere with the expires configuration, we will continue investigation.
  19. mistwang

    mistwang LiteSpeed Staff

    Please download and try the updated 3.2.1 package. you may see uncompressed version being served during the construction of the compressed cache for that file, once the compressed version was built, compressed version will always be served.
  20. aww

    aww Well-Known Member

    I finally got it working. But the problem was not what we thought.

    One thing you never mentioned is that "Auto Update Static" must be turned on.

    That was the entire problem.

    But that is very confusing in the settings. Is it really required to be enabled?

    The first "Enable Compression" option is followed by "Enable Dynamic Compression". That implies the first option is for static files. Any further options are therefore, optional.

    Is it not possible to have static files compressed on the fly without storing .gz verisons first?
    It should be. More overhead yes, but might be necessary in some environments.

    I assume litespeed checks the original file for changes and re-creates the .gz if there is a timestamp difference?
    Last edited: Aug 9, 2007

Share This Page