Netscaler caching mozilla.com despite headers

RESOLVED FIXED

Status

Infrastructure & Operations
WebOps: Other
RESOLVED FIXED
11 years ago
5 years ago

People

(Reporter: clouserw, Assigned: oremj)

Tracking

Details

(URL)

(Reporter)

Description

11 years ago
mozilla.com was updated last night (for bug 378677), and I added another redirect.  I'm using the same 'no-cache' headers that I use for all the other redirects, but the NS is still caching it.  The redirect is:

http://www.mozilla.com/firefox/

Right now it 301's the user to /en-US/firefox/.  It should be sending them to /$lang/firefox/.  We tried clearing the NS cache last night, but it didn't fix it.

Also, don't forget we'll need to do whatever we do here to the .nl boxes.
(Assignee)

Comment 1

11 years ago
Just a note, no one made the config sync out to .nl
(Assignee)

Comment 2

11 years ago
The correct cache control header is not being sent out by the web heads.

[root@nladm01 etc]# /data/bin/hit nlweb01 'http://www.mozilla.com/firefox/'
HTTP/1.1 301 Moved Permanently
Date: Mon, 25 Jun 2007 08:08:21 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://www.mozilla.com/en-US/firefox/
Cache-Control: max-age=900
Expires: Mon, 25 Jun 2007 08:23:21 GMT
Content-Length: 327
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.mozilla.com/en-US/firefox/">here</a>.</p>
<hr>
<address>Apache/2.0.52 (Red Hat) Server at www.mozilla.com Port 80</address>
</body></html>

[root@mradm01 ~]# /data/bin/hit pm-web01 'http://www.mozilla.com/firefox/'
HTTP/1.1 301 Moved Permanently
Date: Mon, 25 Jun 2007 08:08:47 GMT
Server: Apache/2.0.52 (Red Hat)
Location: http://www.mozilla.com/en-US/firefox/
Cache-Control: max-age=900
Expires: Mon, 25 Jun 2007 08:23:47 GMT
Content-Length: 327
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="http://www.mozilla.com/en-US/firefox/">here</a>.</p>
<hr>
<address>Apache/2.0.52 (Red Hat) Server at www.mozilla.com Port 80</address>
</body></html>



(Reporter)

Comment 3

11 years ago
oremj and I looked at this on IRC.  Stage is sending the right headers when I test with it, and stage and production are the same.
Assignee: server-ops → mrz
Apache peculiarities may be at play...

If the redirects are being generated by RewriteRule and the headers in question are being added by an AddHeader directive, RewriteRule happens logically earlier in the response construction process than AddHeader does.  If a rewrite triggers, the header will not be added.

The only way I've ever found to deal with this specific situation is to create an "asis" file which includes all of the headers to be send, both the cache control headers and the redirect headers, and have your redirect do a pass-through to that file instead of actually redirecting.  This requires mod_asis being enabled (I believe it is by default on RHEL) and having the asis handler available (might have to tweak that part).

(Reporter)

Comment 5

11 years ago
The redirect in question here is generated by php with a header() call, so I don't think that's it.  

That said, we've had no luck tracking this down so far...

Comment 6

11 years ago
So I have this bug but I'm not sure why and I'm not sure what the problem is anymore.

In any event, I see that the app is sending out cache headers and the Netscaler appears to be caching.  

Can someone reassign to the right place?
(Assignee)

Comment 7

11 years ago
Taking the bug.
Assignee: mrz → oremj
(Assignee)

Comment 8

11 years ago
Works now.  Somehow the config did not get sent to the web heads.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.