Community Support
January 09, 2009, 08:54:34 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Staff List Login Register  
Pages: [1]
  Print  
Author Topic: Apache problems (was: "Gzip compression disabled?")  (Read 40 times)
Un chien andalou
New User
*
Offline Offline

Hosting Plan: Free Hosting
Posts: 9
Referrals: 0


« on: August 30, 2008, 10:00:08 AM »

Hi.
I'm using the icr38 free hosting.
The service is superb, but... can i ask why the gzip compressione is disabled?

gzencode, gzcompress, ob_gz_handler etc are all disabled and $_SERVER['HTTP_ACCEPT_ENCODING'] doesn't return anything.

Now i'm using the zlib compression and i don't have any problem right now, but i would like to know why it is disabled Smiley

Thanks and sorry for my poor english Tongue
« Last Edit: September 03, 2008, 08:11:25 PM by Un chien andalou » Logged
Andrew
Byteact/i.create Administrator
Administrator
*****
Offline Offline

Hosting Plan: Premium Hosting
Operating System: Linux
Browser: Opera
Posts: 127
Referrals: 2



« Reply #1 on: August 31, 2008, 04:09:03 PM »

Actually, by default all outgoing traffic is compressed when it comes to webpages, scripts, etc... on the free hosting network, we enabled it to help speed things up awhile back.

Essentially, by trying to use gzip on your site, you're compressing already compressed data, zipping a zip file if you will to eek out a few more bits of compression.

PS: Your English is fine Smiley
Logged

Unsolicited private messages for support issues will go unanswered
Un chien andalou
New User
*
Offline Offline

Hosting Plan: Free Hosting
Posts: 9
Referrals: 0


« Reply #2 on: September 03, 2008, 07:11:22 AM »

hm...

anyway, i have another prob: the server send automatically a "Pragma: no cache" header for php files Cry
This is ok for dynamic content but when using php for compressing css and js files (like me Tongue) sending "Pragma: no cache" means that the css/js will never be cached by the browser (they are 70+kb!)

i've tried both
Code:
Header unset Pragma
and
Code:
Header set Pragma "public"
in the htaccess, and even
Code:
header('Pragma: public');
in the php script but none of these works, actually (they works for other headers but not with Pragma?!)

Any other ideas?

It's the pragma header really necessary?
« Last Edit: September 03, 2008, 07:15:03 AM by Un chien andalou » Logged
Andrew
Byteact/i.create Administrator
Administrator
*****
Offline Offline

Hosting Plan: Premium Hosting
Operating System: Linux
Browser: Opera
Posts: 127
Referrals: 2



« Reply #3 on: September 03, 2008, 12:23:42 PM »

If I recall, PHP being a dynamic programming environment where anything is subject to change, automatically adds the no cache headers to anything it creates such as, a CAPTCHA image for example.
Logged

Unsolicited private messages for support issues will go unanswered
Un chien andalou
New User
*
Offline Offline

Hosting Plan: Free Hosting
Posts: 9
Referrals: 0


« Reply #4 on: September 03, 2008, 08:07:46 PM »

If I recall, PHP being a dynamic programming environment where anything is subject to change, automatically adds the no cache headers to anything it creates such as, a CAPTCHA image for example.
maybe, but on my local server there is no such header in the server response Lips Sealed

Anyway, i *think* i've resolved the issue: the solution is to simply (mod_)rewrite the extension of the files (style.php -> style.css for example).
But i'm suffering from headaches trying to figure out what to do with the .php stuff.

Thanks, anyway.

P.S. I noticed the iframe when a php error is displayed... that's ok for me but what about the cookies?
I hope they're not tracking cookies or things like that Tongue
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.7 | SMF © 2006-2008, Simple Machines LLC | Sitemap | Archive Valid XHTML 1.0! Valid CSS!