You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "Michael A. Peters" <mp...@domblogger.net> on 2015/02/24 15:18:35 UTC

[users@httpd] Apache modifying headers from php

Hi,

I have a php wrapper to js / css files

I use mod_rewrite to have the wrapper handle the request.

I then set the cache rules in php via

header('Cache-Control: max-age=' . $this->maxage);

Apache however then serves it as

Cache-Control: max-age=31557600, max-age=0

It seems most clients do the right thing but...

Apache is also adding an Expires header w/ current timestamp, 
over-ridden by the max-age I know, but I'd rather it not be there.

I want Apache to send max-age=0 for most php content, but not for the 
JS/CSS wrapper content.

How do tell apache not to?

I do have mod_expires active but I am only using that for images and 
multimedia served by php, I do not know if mod_expires is doing this or 
apache itself.

Thanks for suggestions.

CentOS 7 with stock CentOS build of apache but php 5.6.x

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


[users@httpd] mod_nss ??

Posted by J Lance Wilkinson <jl...@psu.edu>.
This morning a webserver that I'm responsible for (but didn't have a 
particularly significant hand in setting up) was reporting as <defunct> in a
	$ ps -ef | grep httpd
display.  This is on RHEL6 and it's Apache HTTPD 2.2 patched up the way that
Red Hat does things.

When I explored the logs, and especially after I tried to restart it and got a
[FAILED] report on the start, I found several log entries suggesting SSL 
problems and an unexpired certificate.

But the webserver in question doesn't supply ANY SSL encrypted services.

Turns out what appeared to be a legacy use of mod_nss was present in the 
configuration.

I was able to restore the services by simply commenting out the nss.conf file 
from the /etc/httpd/conf.d directory.

But I'd really like to confirm things by trying to identify just what this 
expired certificate was trying to secure.   The only reference that I can find 
to a specific certificate complains about "Server-cert" and naturally there's 
no such file anywhere in the perview of the server.

Skimming docs on mod_nss, I see that I shouldn't be able to find individual 
certificates, because they're all in a database.

The docs I've found don't tell how to review the contents of the database
which appears to be in three files (cert8.db, key3.db and secmod.db) in a
directory cited in one of the NSS configuration directives, /etc/httpd/alias

The server is one of two that are load balanced.  While the one that failed 
appears to have its database files all timestamped 4 years ago (Feb 23 2011), 
the one that did not has the same files but timestamped a little more recent 
(Dec 6 2011).   So it's likely on or about December 6th I'll observe the same 
issue on that other server.

While my brute force method of recovering the server that expired with its 
certificates overnight seems to alleviated the issue, I'd love to be able to 
definitively say what this was applying to before using the same brute force 
method on the as yet unaffected server.


-- 
J.Lance Wilkinson ("Lance")		InterNet: Lance.Wilkinson@psu.edu
Systems Design Specialist - Lead	Phone: (814) 865-4870
Information Technology Services 	FAX:   (814) 863-3560
Penn State University
ITS Services and Solutions (SaS), 6 Willard, University Park, PA 16802
http://ucs.psu.edu/home/jlw12@psu.edu?fmt=freebusy


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org