Forum Discussion

Ferg_104721's avatar
Ferg_104721
Icon for Nimbostratus rankNimbostratus
Sep 29, 2011

WA behaving differnt depending on VS

Hi All

 

 

I am currently having an issue with WA returning 304 for specific content when moved to another VS. My architecture [see diagram below] is normally that WA is applied on a "Front End" VS, traffic is LBed through to an authenication device (3rd Party, and have check it is not stripping http headers) which routes the authenicated user through to the "Backend VS" doing basic LB to the server for content.

 

 

This setup works great, however in this model we have internal and external facing VS so the WA must handle the user interaction twice, so I have tried to move the WA to the "Backend VS" but once I do this some content is returned as a 304, when normally it is not.

 

 

This content is

 

 

text/css

 

application/x-javascript

 

text/javascript

 

 

 

Originally with WA on Front End VS I did recieve issues like this due to lifetime setting not set correctly which was resolved. I cant find a reason for this to be differnet if i move the WA to the Back End.

 

 

By using irule looking and httpwatch

 

*I can see the the http host name is being passed

 

*the uri info is being passed

 

*pvinfo shows the data is coming from the correct tree location, and beinfg serverd from WebAccelerator memory Smart Cache

 

*the date and expire have the correct 30 expire which i have set in the lifetime

 

*cache-control has public maxage set

 

 

The only thing i can see different from a http watch on the Front End compared to the Back End is the the connection keep-alive header is missing.

 

 

USER----[FE VS (WA)]--lb--[AUTH]--route---[BE VS]------vlan----[SERVER]

 

Any help would be appreciated.

 

 

 

Thanks

 

Ferg

 

 

1 Reply

  • Johnny_Schmidt_'s avatar
    Johnny_Schmidt_
    Historic F5 Account
    WA is going to serve up a 304 for content which is requested with a conditional GET and for which it's cache is valid (either the cache hasn't expired or a conditional request to the OWS returned a 304). Double check your header values for the conditions (If-Modified-Since, etc) to shed light on who is making what decision about when to serve a 304. The S code in the pvinfo header ought to also help figure out who sent the original 304.

     

     

     

    Hopefully that gets you to the right place. You may want to disable RAMCACHE in this situation, making sure it's off on both VS's that the WAM traffic foes through.