If-None-Match breaks with 304 redirection occurs if cached.
Article ID: 166568
Updated On:
Products
Issue/Introduction
If-None-Match breaks with 304 redirection occurs if cached.
ProxySG not forwarding when 304 redirection is sent from OCS.
Resolution
In all HTTP headers you will see the If-Modified-Since which is normal, but in some you will see the If-None-Match.
If you are experiencing issues with a site that is sending a 302 or 301 redirection and is also using the If-None-Match in the HTTP header, you may experience issues with navigating to this URL. This is due to the caching which the ProxySG will do for objects.
If-None-
Match: <tags>
Instead of matching on last-modified date, the server may provide special tags (see ETag) on the document that act like serial numbers. The If-None-Match header
In a packet capture you will see the In-None-Match with a string of numbers. This is the objects identification or “Finger print” id. This is matched by the ETag in the Response from the OCS.
If you see this and you are getting a 304 not modified, this is due to the fact that the object in cache on the ProxySG is matching this If-None-Match. The server will compare this with the original object and confirm that the “finger-print” matches. This cause issue when the OCS is trying to send the ProxySG to retrieve a new Object to load the site, but it is seeing a 304 not modified due to the cached object.
Disabling cache for this Request URL will resolve the issue for sites that are redirecting but are unable to due to 304 not modified objects confirmed by the OCS prevents the ProxySG from requesting the newly changed objects for the redirection. This is not the fault of the ProxySG but how the site was programmed by the developers of the OCS the user attempts to connect to.
How to bypass object caching for specific URLs?
Solutions ID: KB5229
false
Feedback
