Bug ID 623562: Large POSTs rejected after policy already completed

Last Modified: Sep 13, 2023

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

Known Affected Versions:
11.5.1 HF2, 11.5.1 HF3, 11.5.1 HF4, 11.5.1 HF5, 11.5.1 HF6, 11.5.1 HF7, 11.5.1 HF8, 11.5.1 HF9, 11.5.1 HF10, 11.5.1 HF11, 11.5.2 HF1, 11.5.3 HF1, 11.5.3 HF2, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.0, 11.5.1, 11.5.2, 11.5.3, 11.5.4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 12.0.0, 12.0.0 HF1, 12.1.0 HF1, 12.0.0 HF2, 12.1.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.1 HF1, 12.1.1 HF2

Fixed In:
13.0.0, 12.1.2 HF1, 11.6.1 HF2

Opened: Oct 19, 2016

Severity: 3-Major

Symptoms

When the policy has already completed, access still rejects POSTs greater than 64k. Client will see a reset, and these error messages will appear on the BIG-IP: /var/log/ltm Oct 18 19:10:04 bigip6 err tmm[14242]: 01230140:3: RST sent from 10.2.61.80:8080 to 10.2.61.10:55280, [0x1d4cb2c:2863] APM HTTP body too big /var/log/apm Oct 19 09:42:37 bigip3922mgmt err tmm1[7636]: 01490514:3: (null):Common:00000000: Access encountered error: ERR_NOT_SUPPORTED. File: ../modules/hudfilter/access/access.c, Function: hud_access_process_ingress, Line: 2960

Impact

Clients are unable to send POST bodies to '/' that are larger than 64kb, even though the policy has already been evaluated to allow.

Conditions

Policy has already been fully evaluated to allow. Then the client sends a large POST. Only applies to POSTs made to '/'. Would not apply if the URL is something else like '/test'. Also does not apply to clientless modes, where the db key tmm.access.maxrequestbodysize can be used to increase the maximum POST body size allowed.

Workaround

Move the resource from '/' to another URL.

Fix Information

The logic of '/' in this area was changed to be consistent with other URLs.

Behavior Change

Guides & references

K10134038: F5 Bug Tracker Filter Names and Tips