Jump to content
Welcome to our new Citrix community!

Cache-control headers question

Pablo Saco

Recommended Posts



So I'm configuring a new Citrix gateway to provide external access for one of our clients, and they're complaining about a dual cache-control entry, basically like this:

Cache-Control: "no-cache, no-store, must-revalidate"

Cache-Control: "no-cache"


Now I don't really know whether that is acceptable or not, but I also don't know where the 2nd header is coming from as I only have one cache-control action/policy configured in this gateway which is the following:



Did this happen to any of you?



Link to comment
Share on other sites

You don't want to Insert an instance of a header if the header already exists or you will end up with two.  


You may need to change from an insert_http_header to a replace action targeting the cache_control header.

Or switch to two policies, one that uses an expression to say if cache control header exists point to the "replace" action. And one if it doesn't exist, use the insert action.

Link to comment
Share on other sites

So the insert_http_header and delete_http_header actions target headers automatically and you just have to list the header name:  cache-control (and then in the case of insert, what you want to insert in it.)


The delete and replace actions are non-specific and can be used to target all sort of things to delete or replace in requests or responses so you have to tell it in the case of insert, where to insert and what to put there.  For delete just what to target for deletion. This can now be parts of urls/headers/or body content depending on context.


To replace or modify a header:

Target cache-control header by inserting this in the "expression to choose target" field:  http.res.header("cache-control")

Then in the "target" field (aka value) specify the string you want to replace:  "no-cache,no-store,must-revalidate"


You can then use the evaluator or action evaluator to confirm it replaces the existing header and not something else.







Link to comment
Share on other sites

Are you binding the policy to the REQUEST or the RESPONSE time flow?

We are rewriting the response header, so be sure you are on the rewrite response bind point for that vserver.


If you are doing a request time rewrite, then that when involve an http.req.header("<headername>") and would bind to the request time bind point. Though cache-control is usually a response time header.

Also are you binding an HTTP rewite policy to an HTTP/SSL vserver?

Link to comment
Share on other sites

Are you binding to an lb vserver?  If in the GUI, when you do the rewrite bind policies, be sure you click on "policies" to choose new policies and bind points and not the existing "rewrite policies" section or you are binding more request time rewrites (if that's what you already have).  If you click on the "+" for more policies, then you have a choice of request or response once you choose rewrite.


OR go to the rewrite Policy Manager and choose HTTP, lb vserver, <specific vservername, and response (vs request).


Finally from cli you can specify response or request during the lb vserver binding. 



I realize that may not have been the most useful description. So here's a screenshot and a cli example.

If you click the existing rewrite policies on the vserver and they are already request time, you are trying to bind more request-time rewrite policies (red arrow in screenshot).

If you click the "+" sign next to policies, you have the option of binding any policy to the vserver to any flow (depending on feature request or response). Once you choose rewrite on this vserver, you can then choose request or response. if response is still not showing, then none of your policies look like they apply to response time processing, which means an expression issue in the policy or action, probably.


From cli on a vserver, the binding would be indicated in the policy bind "type" field.  Global bindings are a little different.

bind lb vserver lb_vsrv_demo1-policyName rw_pol_req_replacepath -priority 100 -gotoPriorityExpression NEXT -type REQUEST
bind lb vserver lb_vsrv_demo2 -policyName rw_pol_res_removesrvid -priority 100 -gotoPriorityExpression NEXT -type RESPONSE

Edited by Rhonda Rowland
added screenshot to clarify
Link to comment
Share on other sites

You could only insert your custom header if a no-cache header doesn't already exist.


Also be sure you've cleared cache in your browser (and or the NS if caching is enabled) or you will get old responses during your test cycle.

Response time rewrites will not be performed on cmp responses coming from backend servers; features like appfw have their own handling for the cache control headers (this shouldn't be your problem...but the point is there are a lot of other possible impacts).


But you might just want to double check your polic(ies) bindings and whether your rewrite policies are bound with a GoTo END or NEXT and confirm that you are in fact having a policy hit occur.  (Remember if Rewrite is set to END, you will only process first matching policy in that bind point. If you set it to next, you can find multiple policy matches.


Sorry, its not getting you to the answer you need.



Link to comment
Share on other sites

No worries, you've been really helpful, I did take a look at the GoTo field on the policies, that's not an issue right now. I just don't get where this extra no-cache header is coming from, there has to be a policy for it that's there by default somewhere. Whats weird is that the replace action did insert the custom heaeder, but didn't eliminate the other one.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...