DX - Load Balancing & Application Acceleration
DX - Load Balancing & Application Acceleration

[ Generic Cache Question ]

‎10-17-2008 05:47 PM

I have some internet facing web servers that on the back end talk to internal web servers.  The internal web servers are behind a 3280.

 

When they hit a URI, lets say http://internal.site/getfile.cgi?fileid=248t592  and then lets say that variable changes in the next request,  http://internal.site/getfile.cgi?fileid=398hg28d,  why is it that I sometimes get the same file from the first request when the second request is clearly different?

 

Could this be related to the generic nitro app rules rather than cache?  I don't see subsequent hits to the internal web servers, so it appears that the load balancer is making use of the cache.

 

This only seems to happen when our servers are hitting perl code behind a DX and doesn't happen with java code.  That may or may not be a coincidence.  The perl code is rather old and I don't know if it understands any cache controls; but regardless of that difference, I would think that the DX would not serve up the same file for 2 completely different requests.  

 

This actually has some fairly serious privacy implications when one person gets another persons documents so I am trying to better understand how the cache decisions are made.  I have seen this behavior on 5.3.2 and 5.3.4.  This particular pair has not yet been upgraded to 5.3.6.

1 REPLY 1
DX - Load Balancing & Application Acceleration

Re: [ Generic Cache Question ]

‎10-22-2008 07:36 AM

 

The DX cache is based off the URI and does not take into account any query strings, so http://internal.site/getfile.cgi?fileid=248t592 and  http://internal.site/getfile.cgi?fileid=398hg28d are interpreted as /getfile.cgi

 

The apprules within nitro.apprule perform a check to make sure that there is no query string with 'and query_string not_exists' before caching an object e.g.

 

#PTH12
PTH: reply_header "Content-Type" contains "java"
    and reply_header "Cache-Control" not_contains "no"
    and reply_header "Cache-Control" not_contains "private"
    and reply_header "Cache-Control" not_contains "max-age"
    and reply_header "Pragma" not_contains "no-cache"
    and reply_header "Expires" not_exists
    and http_reply_code equals "200"
    and query_string not_exists
    then insert_reply_header "Cache-Control" "max-age=600"
    and update_reply_header "Server" "Concealed by Juniper Networks DX"
    and cache "600"

 

 

Note that tests on the HTTP cache control headers are done within the apprule to allow control over whether you wish to honour the server's instructions on caching or not.   You could add an apprule line near the top of the PTH apprules to catch the .cgi pages which have query strings like:

 

 

PTH: if url ends_with ".cgi"

          and http_reply_code equals "200"
          and query_string exists
          then update_reply_header "Server" "Concealed by Juniper Networks DX"

 

 

As there is no 'and continue' the apprule PTH processing will stop if this matches. 

 

 

 

Announcements

DX SERIES

The Juniper Networks DX application acceleration platform delivers a complete data center acceleration solution for Web-enabled and IP-based business applications.

RSS Icon