Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Being no super-expert with Apache, does anyone know if there is something strange going on? It seems that my reverse proxy setup, doesn't preserve the correct caching headers from the original virtualhost.

Let me explain...

I am currently using PHP Slim to create an API for my web app. It has its own caching mechanisms, which are setup and running fine. So, when visiting the resource api.domain.com/info for example, I have a Last-Modified that is set, which allows it to be cached (it doesn't change very often).

As such, the headers looks something like...

Request URL:http://api.domain.com/info
Request Method:GET
Status Code:304 Not Modified

Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Host:api.domain.com
If-Modified-Since:Mon, 04 Oct 2010 08:00:52 +1100
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5

Response Headers
Connection:Keep-Alive
Date:Tue, 19 Jun 2012 22:34:45 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.21 (Win64) PHP/5.3.8
Vary:Accept-Encoding

Which shows that the resource returns with a 304 - it's been retrieved from cache. Great!

However, the web app accesses this from a reverse proxy (cross domain issues). When accessing the exact same resource, this time from app.domain.com/api/info, it returns with a 200 code. Its also noteably slower to load, which makes me think something isn't working.

This time, the headers are...

Request URL:http://app.domain.com/api/info
Request Method:GET
Status Code:200 OK

Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Host:app.domain.com
If-Modified-Since:Mon, 04 Oct 2010 08:00:52 GMT
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5

Response Headers
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:1959
Content-Type:application/json
Date:Tue, 19 Jun 2012 22:41:01 GMT
Keep-Alive:timeout=5, max=100
Last-Modified:Mon, 04 Oct 2010 08:00:52 GMT
Server:Apache/2.2.21 (Win64) PHP/5.3.8
Vary:Accept-Encoding
X-API-Version:v1.0
X-Powered-By:PHP/5.3.8, Slim

Any ideas? Sorry about the mass of header info above - didn't want to leave out any information...

share|improve this question
    
Which If-Modified-Since header is right? One or the other has a borked time zone. –  David Schwartz Jun 20 '12 at 2:02
    
Well picked up! The If-Modified-Since:Mon, 04 Oct 2010 08:00:52 +1100 is the correct one (AEST). Would that make a difference? –  crawf Jun 20 '12 at 2:08
    
I would check to make sure the time (and time zone) is correctly set on the reverse proxy machine. –  David Schwartz Jun 20 '12 at 2:43
    
It's actually the same physical server, so i'm unsure about how to check that...Besides, they're both the same time, just differing timezone, which has to be fixed, but unfortunately doesn't seem to whats causing the issue... –  crawf Jun 20 '12 at 2:45
    
@crawf if the content was modified in the 11 hours between +1100 and GMT, then yes one of those would have a stale cache. The same day an hour in +1100 and +0000 are not the same time. What are the response headers from api.domain.com the first time (before the client has the resource in its cache)? I do notice the If-Modified-Since and Last-Modified headers have the same time. Maybe that is significant? –  dsh Aug 5 '12 at 2:19
show 1 more comment

1 Answer

When i compare your both example request, I see some more differeneces between them.

e.g. the second response (throught the proxy) includes an

Content-Encoding:gzip

Line. Maybe your reverse proxy adds an gzip compression filter before delivering the results. What could mean: you primary resource did not change and but the proxy changes the content by compressing it, and so it labels this as "new content".

Another difference is in your request: in your first request you send:

If-Modified-Since:Mon, 04 Oct 2010 08:00:52 +1100

but in your second request the timeoffset +1100 is missing, so you`re sending another modification time.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.