NO-Caching certain files with BIP

Well, first I'd recommend a few tweaks to the rule to make it A.) more efficient, and B.) more effective.

I'd use something closer to this:

when HTTP_REQUEST {
  set foundmatch 0
  if { ([HTTP::uri] contains "slide") or ([HTTP::uri] contains "ps") } {
    set foundmatch 1
  }
}
when HTTP_RESPONSE {
  if {$foundmatch == 1} {
    HTTP::header replace Cache-Control no-cache
    HTTP::header replace Pragma no-cache
  }
}

One of the problems this solves is that, in your original example, if the uri contained slide., but not ps., foundmatch would have been set to 0, due to the if/else structure you had in place. This should resolve that, as well as run a bit more smoothly.

Even with these headers set to no-cache, though, I'm not sure that you'll be able to completely stop the downoading of files into the Temporary Internet Files folder, even if that is how it's supposed to behave.

Let us know if you see any improvement or have any other questions.

-Colin

Thanks for that. I put the change in and it is still not working. I'm wondering if I should be using some sort of wild card characters because maybe there isnt a match being made. When you use the "contains" does it just look for that string anywhere in the URI?

 

 

TO be more specific I changed the Irule to match a certain file that is being requested by the client:

 

 

/GET /common/meeting/launcher/openmeetingversioncheck.swf HTTP/1.1

 

 

and changed the Irule to:

 

 

 

when HTTP_REQUEST {

 

set foundmatch 0

 

if { ([HTTP::uri] contains "openmeetingversioncheck.swf")} {

 

set foundmatch 1

 

}

 

}

 

when HTTP_RESPONSE {

 

if {$foundmatch == 1} {

 

HTTP::header replace Cache-Control no-cache

 

HTTP::header replace Pragma no-cache

 

}

 

}

 

 

Still nothing. Any other ideas or suggestions?

To answer your question, yes, the contains operator matches the compared text anywhere in the variable you're referencing. It is not, by default, case insensitive, though. For that, you'd need to use the tolower command.

when HTTP_REQUEST {
  set foundmatch 0
  if { [string tolower [HTTP::uri] ] contains "openmeetingversioncheck.swf" } {
  set foundmatch 1
  }
}
when HTTP_RESPONSE {
  if {$foundmatch == 1} {
    HTTP::header replace Cache-Control no-cache
    HTTP::header replace Pragma no-cache
  }
}

I'm not convinced this is your problem, though. Have you confirmed yet whether or not the headers are being replaced?

If you do a tcpdump on the interface that's sending the traffic back to the client, or on the client machine itself, you should be able to see whether or not the headers you're trying to modify are being replaced or not.

If they are, and you're still having an issue with the files being cached, then you'll likely need to research what else needs to be done to prevent this, if it's possible.

-Colin

Ok it looks like the headers are being changed based on my sniffer:

 

 

GET /common/meeting/launcher/openmeetingversioncheck.swf HTTP/1.1

 

Accept: */*

 

x-flash-version: 8,0,22,0

 

Accept-Encoding: gzip, deflate

 

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

 

Host: conference2.telept.com

 

Connection: Keep-Alive

 

Cookie: BREEZESESSION=breezdi22gcqu8fnxhczw

 

 

HTTP/1.0 200 OK

 

Date: Mon, 17 Oct 2005 18:39:24 GMT

 

Content-Type: application/x-shockwave-flash

 

X-Breeze-Cache: appserv/web/common/meeting/launcher/openmeetingversioncheck.swf

 

Content-Length: 5980

 

X-Breeze-Public-Map: /common/,appserv/web/common/

 

Connection: keep-alive

 

Last-Modified: Fri, 19 Aug 2005 23:00:40 GMT

 

Server: JRun Web Server

 

Cache-Control: no-cache

 

Pragma: no-cache

 

 

However, the files are still caching. What is very strange is that I was using apache server before I started trying BIG IP and it worked using this command in a virtual host within apache:

 

 

 

Header unset Cache-Control

 

Header add Cache-Control no-cache

 

Header add Pragma no-cache

 

 

 

And it worked great. Everyone told me how much control you had over traffic with the Big IP, so thats why we're trying it --- ughh!

 

 

If I use a * in the "contains" will it match all files? Maybe it is only not working for some files?

 

 

Well, it looks like your rule is performing as expected. It is setting the no-cache information as desired, but the browser is still caching things.

 

 

You could certainly try broadening the matching requirements like you mentioned, to see if it's a different file that's being cached. The rule appears to be functioning as intended, though.

 

 

-Colin

You might try sniffing what the response looks like when using the Apache server to disable the caching and then comparing the response headers to see what the differences are. Our caching guru (bl0ndie) went home for the night, maybe he will chime in later...

So here is the difference with a specific GET between Apache and BigIP

 

 

Apache Headers:

 

 

GET /common/meeting/shell/StamperSymbols.swf HTTP/1.0

 

Referer: http://conference.telept.com/common/meeting/shell/StamperSymbols.swf

 

x-flash-version: 7,0,55,312

 

User-Agent: Shockwave Flash

 

Host: conference.telept.com

 

Connection: Keep-Alive

 

Cookie: BREEZESESSION=breezvnisv9urvxpgh7zo

 

 

HTTP/1.1 200 OK

 

Date: Tue, 18 Oct 2005 17:46:15 GMT

 

Server: JRun Web Server

 

X-Breeze-Cache: appserv/web/common/meeting/shell/StamperSymbols.swf

 

Last-Modified: Fri, 19 Aug 2005 23:01:46 GMT

 

X-Breeze-Public-Map: /common/,appserv/web/common/

 

Content-Type: application/x-shockwave-flash

 

Content-Length: 1679

 

Cache-Control: no-cache

 

Pragma: no-cache

 

Connection: close

 

 

************************************************

 

************************************************

 

 

BigIP Headers:

 

 

 

GET /common/meeting/shell/StamperSymbols.swf HTTP/1.0

 

Referer: http://conference2.telept.com/common/meeting/shell/StamperSymbols.swf

 

x-flash-version: 7,0,55,312

 

User-Agent: Shockwave Flash

 

Host: conference2.telept.com

 

----------: ----------

 

Cookie: BreezeLoginCookie=craig.freyman@medpt.com; BREEZESESSION=breezcbwyo2qhiz83sxbo

 

 

HTTP/1.0 200 OK

 

X-Breeze-Cache: appserv/web/common/meeting/shell/StamperSymbols.swf

 

Last-Modified: Fri, 19 Aug 2005 23:01:46 GMT

 

Connection: close

 

X-Breeze-Public-Map: /common/,appserv/web/common/

 

Content-Type: application/x-shockwave-flash

 

Date: Tue, 18 Oct 2005 17:35:49 GMT

 

Content-Length: 1679

 

Server: JRun Web Server

 

Pragma: no-cache

 

Cache-Control: no-cache

 

 

 

 

 

As you can see it looks like the BigIP is inserting the No-Cache headers after the connection is already closed, and apache inserts them AND THEN calls the "Connection: close"

 

 

-Craig

 

 

In our experience with HTTP clients and servers, we have not come across any that are intentionally sensitive to the ordering of non-duplicate headers in the request or response.

 

 

If I were to make a guess, I think the problem *might* be related to the HTTP/1.0 response from the server in the second instance. To explain, the Cache-Control directive is explicitly an RFC2616 directive, and HTTP/1.0 clients should not be expected to understand it. As an interim workaround, HTTP server vendors added the "Pragma: no-cache" directive. However, pragmas are advisory, not mandatory. RFC2616 section 14.32 goes so far as to say:

 

 

 

Note: because the meaning of "Pragma: no-cache as a response

 

header field is not actually specified, it does not provide a

 

reliable replacement for "Cache-Control: no-cache" in a response

 

 

 

So the question I have is whether the client (a) ignores Pragma: no-cache, and (b) ignores Cache-Control: directives coming back from an HTTP/1.0 server.

 

 

Can you run your test so that the response through the BIG-IP comes back as an HTTP/1.1 response?

That is the track I was going down. When I changed my browser settings to use HTTP 1.1 it works great. So now I'm trying to figure out why the Pragma: no-cache is not working for 1.0 clients. I belive it has something to do with an Expires tag, also.

 

 

In any case, is there a way to redirect someone to a different page if I can detect that they are using HTTP 1.0?

In any case, is there a way to redirect someone to a different page if I can detect that they are using HTTP 1.0?

Sure. You can use the

HTTP::version

accessor. It returns "0.9", "1.0", or "1.1", depending on the headers being sent.