[Fixed] expires on php files using perl regex or using Expire by Type causes default PHP to be used

[Majestic]

Hi Guys,

I believe I have found an error/bug on Litespeed Web Server Open 1.4.13.

This is very easy to duplicate and can be done a couple of ways but first let me try and explain what I am trying to achive.

What I would like to do is add a few extra headers as well as adding expire times when your accessing php files. To be exact I am trying to add the following..

Expire by Type
application/x-httpd-php=A0, application/x-httpd-php-source=A0, application/x-httpd-php3=A0, application/x-httpd-php3-preprocessed=A0, application/x-httpd-php4=A0, application/x-httpd-php5=A0

Extra Headers
Cache-Control: "no-store, no-cache, must-revalidate, max-age=0"
Pragma: "no-cache"

Now if you add the Expire by Types on the vhost level general page and then try and curl -i URL, you will find that its actully using the default/server level PHP and if your using SuEXEC by Daemon (like I am), it knocks it off (uses default user of web server) even tho its also set on server level as well to use SuEXEC. You can see below...

HTTP/1.1 200 OK
X-Powered-By: PHP/7.0.0RC5
Content-Type: text/html; charset=UTF-8
Date: Sun, 08 Nov 2015 16:49:47 GMT
Server: LiteSpeed
Cache-Control: public, must-revalidate, proxy-revalidate​

Do note that this Cache-Control flag is being pulled atm from the contex of / but was in the middle of changing to use regex solution so I can have a differernet header based of file types. However with this on or off, makes no difference due to this bug.

The reason why I noticed this error was because I still have the X-Powered-By flag still turned on the default/server level and is runnning PHP7 vrs my usual vhost level PHP 5.1.16 else I may of not noticed for a while.

You can also confirm that the user is wrong by using some simple PHP code..

<?php system('whoami'); ?>​

If you curl that url you will get..

HTTP/1.1 200 OK
X-Powered-By: PHP/7.0.0RC5
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 08 Nov 2015 16:53:18 GMT
Server: LiteSpeed
Cache-Control: public, must-revalidate, proxy-revalidate​

www-data​

Which is very wrong (this is the default/web server user).

I have tried to do it using the contex part within the vhost by using perl regex say...

exp:.*(?hp|cgi|pl)$​

Which does pickup the php files, however it does the same thing i.e. using wrong PHP. You can test to make sure its doing what it should be by just adding say a X-TEST: Yes flag and confirming via curl -i that its picking up the extra header and this does work as intended, however its using the wrong PHP (not using vhosts level like it should be).

If I remove the expires on PHP pages, it works as it should i.e. using vhost level php settings/user as shown below..

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 26
Date: Sun, 08 Nov 2015 16:55:59 GMT
Server: LiteSpeed
Cache-Control: public, must-revalidate, proxy-revalidate

testsite5.example.co.uk​

Which is correct. It seems as soon as your using PHP expire settings whether its done via general or contex via regex, it just breaks it all. I have even tried to use the regex and just use the default expire settings box but but it does the same.

What I was trying to do to make it easier to mirgrate some stuff over was to use contex based expire based of file extention not by type as thats how the existing setup is, however doing it either way doesn't work as it should.

Now I can syslink the same version I use for vhost level php for default i.e. replace php7 with php5 however theres no point as the php is still being ran as the wrong user anyway even tho the settings are correct even on the server level, its as though it just ignores everything.

I hope this all makes sence, if not or you require further information, please drop me a line and I do my best as I would really like to be able to have custom header info and expires on php files as some users want their php files cached and others do not.

 

[NiteWave]

not very clear about the issue you've described. since it's about open litespeed, and this forum is for enterprise litespeed, so by the chance I did some tests on apache and enterprise litespeed. just an reference for your question while not direct reply.

on both apache and litespeed (not open), on .htaccess:
ExpiresActive On
ExpiresByType application/x-httpd-php A0
ExpiresByType text/html A0

test command: #curl -I 127.0.0.1:8080/p.php

empty .htaccess:
HTTP/1.1 200 OK
Date: Mon, 09 Nov 2015 09:15:07 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.3
Connection: close
Content-Type: text/html; charset=UTF-8

.htaccess:
ExpiresActive On
ExpiresByType application/x-httpd-php A0
HTTP/1.1 200 OK
Date: Mon, 09 Nov 2015 09:15:40 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.3
Connection: close
Content-Type: text/html; charset=UTF-8

.htaccess
ExpiresActive On
ExpiresByType text/html A0
HTTP/1.1 200 OK
Date: Mon, 09 Nov 2015 09:16:13 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.3
Cache-Control: max-age=0
Expires: Mon, 09 Nov 2015 09:16:13 GMT
Connection: close
Content-Type: text/html; charset=UTF-8

so the conclusion:
ExpiresByType application/x-httpd-php A0
is completely ignored for .php
ExpiresByType text/html A0
take effect on .php, apache will add 2 response headers:
Cache-Control: max-age=0
Expires: Mon, 09 Nov 2015 09:16:13 GMT

similar test results for enterprise litespeed,as apache, so omit the test output here.
this is reasonable result and should act like this way.

 

[Majestic]

Hi there,

First of, my applogies, I believed the forum was for both versions.

FYI, I am not using Apache (ewwww), these are just native litespeed configs, so the info you have said is sadly ilrelevent.

As you have said that this is for Enterprise version, I see little point in me trying to explain here using another way with pictures etc, or if you would like me to, I gladly will.

May I ask where do I go for some support for the Open Litespeed version? is there a forum? irc? mailing list? somewhere? as I do beleive what I have found is a bug.

I do have another work around if necessary I can run haproxy infront of the litespeed server and fix the expires/headers that way or run nginx, however I would idealy like to do it within Litespeed itself to make things easier managmnet wise.

Thank you in advance.

Kind Regards,

Simon

 

[NiteWave]

the web admin console for both litespeed are similar, most part are common. you can post the picture here.
how did you add "Expire by Type" in open litespeed GUI ?

if you want to add a expire header for .php, like
Expires: Mon, 09 Nov 2015 09:16:13 GMT

base on my previous test, you may try

Expire by Type
text/html=A0

instead of

Expire by Type
application/x-httpd-php=A0

 

[Majestic]

HI there,

Thank you very much for your reply.

If I do this, the same problem happens.





Note the PHP7, which is wrong.

If I add the type in via general page, it uses the correct version of PHP still (i.e. vhost level) but its not accepting the expire info. I have on purpose added it to 60 seconds to prove that the curl/output is not showing up. I would expect an expire line of 60 secs in the future.



curl output below..



I hope this makes sence, if not let me know and I will try and think of another way on how to explain.

Thanks in advance.

Simon

p.s. I can if you wish send you the httpd_config.conf and the vhconf.conf and just adjust the domain details if you wish. This is just the dev box while I get everything all worked out, then will be rebuilt on to the final server(s) and data mirgrated from nginx/php-fpm. I have tried this several different ways and it still seems to be ignoring. Everything seems to be working perfectly and benchamrks are amazing, but I cant seem to get the expire/header info correct. We need to be able to have diffenet expire info for different files as well as slightly different Cache-Control headers depening on what files used.

 

[NiteWave]

Sorry for late response.
can you give web admin access ( :7080) in PM, so we can work closer.

 

[Majestic]

Hi NiteWave,

No worries ref late responce also mine BTW as sadly ive been quite ill for the past couple of days, but im a bit better now.

I will arrange some login info and some test urls shortly on the litespeed dev server shortly so that you can mess when you get chance.

And BTW, thank you as this is the only thing which is stopping me from moving over to your software.

 

[NiteWave]

confirmed it's a open litespeed 1.4.13 issue.
but tested ok on lsws 5.0.8

reproduce steps:
1. vhost php Script Handler set to vhost level external App: lsphp 4.4.9
server level php Script Handler set to lsphp 5.x

2. define a "Static" context in vhost (note: not LiteSpeed SAPI context):

URI: exp:.*(?:php)$
Location:$DOC_ROOT/$0

3. access test-domain-or-ip/phpinfo.php
show php version is lsphp 5.x -- server level php

4. remove Static context defined in step 2, go step 3, show php version is lsphp 4.4.9 ( as expected)

tested on lsws 5.0.8, no such issue. so only exists on open litespeed.

 

[Majestic]

thank you for confirming and all your hard work.

 

[mistwang]

We have fixed this internally, the change involved is pretty big, please wait for 1.4.14.

 

[Majestic]

Hi there,

Thank you very much for getting this all fixed and for keeping me in the loop.

No rush, I wont be implmenting/mirgrating until everythings been fully tested on the dev network as the whole reason for mirgrating is to improve proformance. After this has all been tested/benchmarked etc, I will start building the final server(s) with the final config whcih will be worked out on the dev envirment.

Thanks again for all your hard work and im sorry it was a BIG change,

Simon

p.s. please make sure suexec still works with your changes as well as the custom headers on php pages, thank you as I found this bug stopped that from working as well.

 

[mistwang]

1.4.14 has been released, you can give it a try.

 

[Majestic]

1.4.14 has been released, you can give it a try.

Thank you for the update.

I will give it a whirl in a couple days time as I'm a little busy with other projects right now.

I will let you know how it goes.

Thank you again for getting this done and tested.

Kind regards.

Simon

 

[Majestic]

Hi Guys,

Just a quick update, sadly works been real busy lately so I haven't had chance to test the patch fully or even apply it, however I should have some time free to go back to the webserver project(s) / mirgrations in a few days so I will let you know after its fully tested and benchmarked before making the final versions.

Again thank you for all your hard work on resolving.

Regards,

Simon

 

[Majestic]

1.4.14 has been released, you can give it a try.

Hi there,

So sorry for the extreame delay, its highly unlike me.. you know what its like at this time of year.

Anyway, I can sucessfuly confirm that upgrading to 1.4.14 does correct this issue and allows custom headers/expire times as well as staying on the correct php version i.e. vhost level.

I shell be doing some further testing tonight to make sure no other bugs or problems persists but from a quick first glance it looks perfect, thank you. After this has been all done and tested, I will start creating the new final replacment web cluster.

Thank you again to your team for all your hard work and squshing this bug.

If I find anything else, I will let you know.

Kind Regards,

Simon

 

[mistwang]

thanks for the confirmation.