Re: Response headers set by apache (Apache Users)

Thanks Rainer for the tips. Here is the follow up.

1. Added ""%{Expires}o"" to logging valve pattern in the server.xml, sets the correct headers expires on the webserver side, doesn't set the 1994 year one. But still when I look at the browser, the double header appear the one from 1994 and the one generate correctly by webserver.

2. Mod_jk log, I turned on the trace as you suggested. And It was a bit hard to read, really many information come out of it, but I found out for my css file, the correct header expires value arrives from my server and not the one from 1994.

So it seems pretty sure that the issue is now on the apache side, as the tomact appserver seems to be showing the right response headers in both cases.

I searched for the string 786297600 in my apache webserver directory, and I had no success with the search, didn't find anything. This is how I looked:

grep -r '786297600' .

grep -r '786297600' *

In the meantime I've found a working solution. But it's not a really great one. In my apache config, in the VirtualHost section I have this :

Header always unset Cache-Control

Header always unset Expires

So when I do this, only the one Expires header set by the webserver (the right one) is left when I inspect the response. This even further adds the suspicion of the expires response header being set by the apache webserver.

This above works but it's not a great, because the mod_headers has no concept of the types (as far as I know). And I want to cache only static files.

So my question is what to do next? I mean what would you do, it's really interesting and confusing at the same time.

Is it possible that this is a bug on the webserver (unlikely) but still what to do next? I'm really out of ideas, this is the day 3 of staring at the console and logs.

Thanks,

Emir

On Sat, May 30, 2015 at 7:45 AM, Rainer Jung <rainer.jung@xxxxxxxxxxx> wrote:

Am 30.05.2015 um 02:26 schrieb Emir Ibrahimbegovic:

I've got an app that runs on a tomcat web server, and I use mod-jk on my
apache web server side.

I think I've managed to configure everything to work seamlessly, I ran
into issues when I wanted to cache static assets on webserver, for some
reason my response headers expires is set to **1994**, these are my
headers for one of the _javascript_ files I want to server as static asset
and cache it:

Accept-Ranges:bytes
Cache-Control:no-cache
Connection:Keep-Alive
Content-Encoding:gzip
Content-Type:application/_javascript_
Date:Fri, 29 May 2015 23:18:25 GMT
ETag:W/"604348-1432950682000"
Expires:Thu, 01 Dec 1994 16:00:00 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Fri, 29 May 2015 23:18:25 GMT
Server:Apache
Transfer-Encoding:chunked
Vary:Accept-Encoding

Before trying to fix it I would first analyze, where the strange value comes from.

You can

- Add ""%{Expires}o"" to the access log valve pattern in your tomcat server.xml and check in the access log, whether the 1994 value is already being sent by your webapp.

- you can switch you JkLogLevel for a temporary test to "trace" and do a single request. mod_jk will log all headers it receives from Tomcat in its own log, so you can check which response headers arrive at the Apache web server.

If the wrong header originates in your webapp, first try to fix it there. Only as a last resort, try to overwrite them in the web server. If you don't even find it among the ones that mod_jk logs, it must be even inside your web server or between your web server and the client. The Apache httpd server by itself would not use such a strange date.

You might also look for the string 786297600 somewhere in configurations or your webapp, because that is the seconds since the epoch that would result in December 1st, 1994, 16:00 GMT. Is it always exactly the same value?

Regards,

Rainer

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx