Bug ID 833213: Conditional requests are served incorrectly with AAM policy in webacceleration profile

Last Modified: May 29, 2024

Affected Product(s):
BIG-IP AAM(all modules)

Known Affected Versions:
13.1.1, 13.1.1.2, 13.1.1.3, 13.1.1.4, 13.1.1.5, 13.1.3, 13.1.3.1, 13.1.3.2, 13.1.3.3, 14.0.0, 14.0.0.1, 14.0.0.2, 14.0.0.3, 14.0.0.4, 14.0.0.5, 14.0.1, 14.0.1.1, 14.1.0, 14.1.0.1, 14.1.0.2, 14.1.0.3, 14.1.0.5, 14.1.0.6, 14.1.2, 14.1.2.1, 14.1.2.2, 15.0.0, 15.0.1, 15.0.1.1, 15.0.1.2, 15.1.0, 15.1.0.1, 15.1.0.2, 15.1.0.3, 15.1.0.4, 15.1.0.5, 15.1.1, 15.1.2, 15.1.2.1

Fixed In:
15.1.3, 15.0.1.3, 14.1.2.3, 13.1.3.4

Opened: Oct 03, 2019

Severity: 3-Major

Symptoms

HTTP 1.1 allows a conditional request with header If-Modified-Since or If-Unmodified-Since to determine whether a resource changed since a specified date and time. If AAM is provisioned and its policy is assigned to a virtual server, it may incorrectly respond with 304 Not Modified, even after the resource was updated.

Impact

Client does not receive an updated resource.

Conditions

-- AAM is provisioned and webacceleration policy is attached to a virtual server. -- Client sends a conditional request with If-Modified-Since or If-Unmodified-Since header. -- The BIG-IP system responds from AAM cache.

Workaround

Use webacceleration profile without AAM policy for resources that require conditional checks falling back into Ramcache.

Fix Information

The BIG-IP system now respects If-Modified-Since or If-Unmodified-Since header and provides an appropriate response for the requested resource when compared to the date supplied in either header.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips