homepage Welcome to WebmasterWorld Guest from 54.235.36.164
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Pubcon Platinum Sponsor
Visit PubCon.com
Home / Forums Index / Code, Content, and Presentation / Apache Web Server
Forum Library, Charter, Moderators: Ocean10000 & incrediBILL & phranque

Apache Web Server Forum

    
gzip mod deflate
glimbeek




msg:4249818
 1:47 pm on Jan 6, 2011 (gmt 0)

Hi,

I've been reading up on this and I've been trying out a fair few different .htaccess solutions for my problem but to no avail.

My "problem" is that I want to compress html, css, php, xml, js and maybe images when people send a request to my server AKA visit my website.

Every "solution" I find, doesn't seem to work. As in, nothing get's compressed.

For instance I tried:

<ifModule mod_gzip.c>
mod_gzip_on Yes
mod_gzip_dechunk Yes
mod_gzip_item_include file \.(html?|txt|css|js|php|pl)$
mod_gzip_item_include handler ^cgi-script$
mod_gzip_item_include mime ^text/.*
mod_gzip_item_include mime ^application/x-javascript.*
mod_gzip_item_exclude mime ^image/.*
mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</ifModule>

and:

# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

# Or, compress certain file types by extension:
<Files *.php>
SetOutputFilter DEFLATE
</Files>

But the results are the same, nothing is compressed. If I turn on gzip compression in Joomla the only thing that get's compressed is the basic HTML that's requested. CSS, etc.. isn't compressed.

There are several websites that you can use to "check" if you compress your content and they say my website is actually sending compressed files on request but Yslow or Page Speed tell a different story.

I'm using Joomla and I enabled gzip. It works on some files but on most it doesn't.
I tried installing extensions that do can do this for you, but they don't work flawless. They compress to much and/or in the wrong order which breaks javascript etc..

I looked into google's mod_pagespeed but that's to much Beta at the moment for my liking. Plus I'd need my host to work with me to get it installed and I can't "test" it before I install it. I'd like to test it and make sure my website doesn't break by installing a apache module.

I contacted my host about my compression problems, but they react in a fashion where this isn't a problem and fixing it should be common sense. I however lack the "common sense" to sort this out. So any help is greatly appreciated (:

 

glimbeek




msg:4253319
 3:58 pm on Jan 14, 2011 (gmt 0)

Hi Jim,

Cheers for the bump.

I'm getting more and more confused. I have 2 websites at the same host. One is running on Direct Admin the other one is cPanel. Direct Admin works, cPanel doesn't. Even my host has difficultly figuring it out. That could of course mean I have a crappy host (:

Anyway, I spoke to 2 different tech support guys today from my host. According to them, the problem lies with cPanel. Atleast that's there best guess so far. Does anyone know if cPanel is hard(er) to configure when it comes to compression?

coopster




msg:4253341
 4:23 pm on Jan 14, 2011 (gmt 0)

There are several websites that you can use to "check" if you compress your content and they say my website is actually sending compressed files on request but Yslow or Page Speed tell a different story.


If you are using an antivirus (and/or firewall combination) program, are you certain they are not clipping your compression request headers before the request is sent? You can use the LiveHttpHeaders plugin for Firefox to be certain.

glimbeek




msg:4253342
 4:26 pm on Jan 14, 2011 (gmt 0)

I'm using:

Live HTTP Headers
YSlow
and Page Speed

I also use websites to check if compression is on. It's not that compression doesn't work at all. The problem is that only the HTML is being compressed. There's no compression on javascript or css files. Sorry if that wasn't clear enough.

coopster




msg:4253354
 4:39 pm on Jan 14, 2011 (gmt 0)

OK. Then it may be the version of Apache you are running. Here is some further reading if you have not already absorbed the Apache docs on >= 2.1 and filtering:

AddOutputFilterByType Compatibility:
Available in Apache 2.0.33 and later;
deprecated in Apache 2.1 and later


[httpd.apache.org...]
[httpd.apache.org...]

StupidScript




msg:4259231
 11:58 pm on Jan 27, 2011 (gmt 0)

My "not being compressed" issue (using mod_deflate) seems to involve requests with a query string appended, as Drupal does with every .css and .js file. Here's some LiveHttpHeader output (with irrelevant clutter removed):

http://example.com/

GET / HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate

HTTP/1.1 200 OK
Server: Apache/2.2.15 (Fedora)
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
----------------------------------------------------------
http://example.com/modules/node/node.css?n

GET /modules/node/node.css?n HTTP/1.1
Accept: text/css,*/*;q=0.1
Accept-Encoding: gzip,deflate

HTTP/1.1 304 Not Modified
Server: Apache/2.2.15 (Fedora)
Vary: Accept-Encoding,User-Agent

Note that the first request for the index file IS compressed, while the second request for a css file with a tiny query appended is NOT compressed.

Just adding to the pile. I don't find any restrictions on query strings in the Apache docs.

SevenCubed




msg:4259243
 12:53 am on Jan 28, 2011 (gmt 0)

Here's what I have applied on my server and it works like a charm. Very small script. Note that this is for mod_deflate as opposed to the older version mod_gzip and assumes that you know it's loaded; if not then adjust it by enclosing it in a <IfModule mod_deflate.c> otherwise just as is below should work fine:

<FilesMatch "\.(php|css|html?|xml|txt|js|pl)$">
SetOutputFilter DEFLATE
</FilesMatch>


I have this applied in the httpd.conf file, I'm not sure if you need to vary it slightly for use in .htacess -- maybe someone else can jump in and assess it.

It's probably better to list the extensions in the order that you know are the most frequently accessed. Also, do not add image files to compression because they are already compressed and it could actually make it worst and slow things down.

Oh yeah and don't forget to reload your configuration file afterward.

glimbeek




msg:4259318
 7:36 am on Jan 28, 2011 (gmt 0)

I contacted my host and they rebuild apache with mod_deflate properly configured and now it works. Thanks for all the suggestions.

StupidScript




msg:4259588
 5:39 pm on Jan 28, 2011 (gmt 0)

Excellent! Thanks for that, SevenCubed. In my Drupal case, it seems that Drupal was handling those files, and when I activated compression in the Performance section of its management interface, .css and .js files were compressed properly.

coopster




msg:4259596
 5:47 pm on Jan 28, 2011 (gmt 0)

Also, you're second request example would not be compressed because no content is returned therefore nothing to compress:

Note that the first request for the index file IS compressed, while the second request for a css file with a tiny query appended is NOT compressed.
HTTP/1.1 304 Not Modified 
Server: Apache/2.2.15 (Fedora)
Vary: Accept-Encoding,User-Agent

StupidScript




msg:4259695
 9:37 pm on Jan 28, 2011 (gmt 0)

I think the 304 status message indicates that the content was simply not modified by the server on its way out. Please correct me, if I'm wrong.

I know for sure that the file was received, along with all of the other .css and .js files that indicated the same status in LiveHttpHeaders.

jdMorgan




msg:4260852
 10:58 pm on Jan 31, 2011 (gmt 0)

It means that that content has not been modified since the date that your browser sent in its IF-Modified-Since request header, and that therefore, your browser should simply render the copy of that content that is already in its cache.

There's no use using a headers checker without this:

[w3.org...]

Jim

StupidScript




msg:4261309
 6:10 pm on Feb 1, 2011 (gmt 0)

I was using this reference: [w3.org...]

I have always read that to mean that if the client has already cached the file, then it must use the cached copy, however if the client has not cached it yet, then the client makes a second request and the server delivers it. I was responding to the note that "second request example would not be compressed because no content is returned therefore nothing to compress", which ends up being true in my case, as I had already cached the file. I f I had not yet cached the file, then, you're right, there would have been a second request with a different result code.

Sorry for the confusion.

jdMorgan




msg:4263815
 7:36 pm on Feb 7, 2011 (gmt 0)

If the response is 304-Not Modified, then the server never invokes any content-handling at all. Therefore, the compression function won't be invoked (it certainly shouldn't be, since there is no content).

It's important to understand the subtleties here: The 'decision factor' is not whether the client has cached the content in a general way, it is whether the client sent an If-Modified-Since header with its request that indicates a date that is *after* the most recent change to the resource on the server.

If the last-modified date of the version cached by the client is older than that stored on the server, the server will send the new version with a 200-OK status. The client will then cache that, along with the new Last-Modified date returned by the server.

If the version cached by the client is still current, then the server sends back a 304-Not Modified response and terminates the transaction without invoking any content-handling.

Jim

StupidScript




msg:4263851
 8:27 pm on Feb 7, 2011 (gmt 0)

Thanks. That makes perfect sense, to me.

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Apache Web Server
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved