You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by Emir Ibrahimbegovic <em...@gmail.com> on 2015/05/30 02:26:08 UTC

[users@httpd] Response headers set by apache

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

Per the instructions I found on [this website][1] I tried to set it inside
my virtual host, like in the example below :

    <VirtualHost *:80>
        Alias /assets /opt/www/tomcat/webapps/ROOT/assets
        ServerName dev.myurl.com
        ServerAlias anotherone.myurl.com
        ErrorLog "|/opt/www/apache/2.2.25/bin/rotatelogs
/opt/www/logs/apache/app/_error_log-%Y-%m-%d-%H 86400"
        CustomLog "|/opt/www/apache/2.2.25/bin/rotatelogs
/opt/www/logs/apache/app/_access_log-%Y-%m-%d-%H 86400" common
        JkMount /* workerdev
    #---   Disabled Trace  -------
    RewriteEngine  On
    RewriteOptions inherit
    #----------------------------
    ExpiresActive On
    ExpiresByType application/x-javascript "now plus 1 months"
    </VirtualHost>

  [1]: http://www.simonwhatley.co.uk/how-to-set-an-expires-header-in-apache

This is my first time doing something like this, so I m not sure what else
do I need to do, and why is there this default `Expires`.
It has been like 9 or 10 hours of different experimenting and none of it
worked.
Any suggestions what else could I try?

**Additional details:**
It seems like that I'm able to add a http header or but can't override the
existing value, by adding this to the `VirtualHost`

    Header unset Cache-Control
    Header add Cache-Control "max-age=290304000, public"

    Header unset Expires
    Header add Expires "Thu, 01 Dec 2015 16:00:00 GMT"

I get this for the response headers :

    Cache-Control:no-cache
    Cache-Control:max-age=290304000, public
    Expires:Thu, 01 Dec 1994 16:00:00 GMT
    Expires:Thu, 01 Dec 2015 16:00:00 GMT

Very odd right? Where else could this header values be set from?

Re: [users@httpd] Response headers set by apache

Posted by Emir Ibrahimbegovic <em...@gmail.com>.
Hi Kurtis,

It is a possibility I guess, but my timezone is EST.

Thanks,
Emir

On Mon, Jun 1, 2015 at 3:14 PM, Kurtis Rader <kr...@skepticism.us> wrote:

> On Mon, Jun 1, 2015 at 11:18 AM, Emir Ibrahimbegovic <
> emir.ibrahimbegovic@gmail.com> wrote:
>>
>> 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? - Yes it's always the same value
>>
>
> It's possible that the value is also expressed in local time and is
> converted to UTC. Is the local time for your server in timezone UTC+8 by
> any chance? For example, the Phillipines, Brunei or western Australia?
> Because that would yield a local timestamp of  786326400, 1994-12-02
> 00:00:00 local time. I would recommend searching for values in the range 786297600
> +/- n * 3600 for n in -12....+12.
>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

Re: [users@httpd] Response headers set by apache

Posted by Kurtis Rader <kr...@skepticism.us>.
On Mon, Jun 1, 2015 at 11:18 AM, Emir Ibrahimbegovic <
emir.ibrahimbegovic@gmail.com> wrote:
>
> 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? - Yes it's always the same value
>

It's possible that the value is also expressed in local time and is
converted to UTC. Is the local time for your server in timezone UTC+8 by
any chance? For example, the Phillipines, Brunei or western Australia?
Because that would yield a local timestamp of  786326400, 1994-12-02
00:00:00 local time. I would recommend searching for values in the
range 786297600
+/- n * 3600 for n in -12....+12.



-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

Re: [users@httpd] Response headers set by apache

Posted by Emir Ibrahimbegovic <em...@gmail.com>.
One more thing,

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? - Yes
it's always the same value

On Mon, Jun 1, 2015 at 2:03 PM, Emir Ibrahimbegovic <
emir.ibrahimbegovic@gmail.com> wrote:

> Thanks Rainer for the tips. Here is the follow up.
>
> 1. Added  "&quot;%{Expires}o&quot;" 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 <ra...@kippdata.de>
> 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 "&quot;%{Expires}o&quot;" 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@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>>
>

Re: [users@httpd] Response headers set by apache

Posted by Emir Ibrahimbegovic <em...@gmail.com>.
Thanks Rainer for the tips. Here is the follow up.

1. Added  "&quot;%{Expires}o&quot;" 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 <ra...@kippdata.de>
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 "&quot;%{Expires}o&quot;" 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@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>

Re: [users@httpd] Response headers set by apache

Posted by Rainer Jung <ra...@kippdata.de>.
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 "&quot;%{Expires}o&quot;" 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@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org