Bug ID 739945: JavaScript challenge on POST with 307 breaks application

Last Modified: Nov 07, 2022

Bug Tracker

Affected Product:  See more info
BIG-IP ASM(all modules)

Known Affected Versions:
11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3,,,,, 11.6.4, 11.6.5,,,, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3,,,,,,,, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0,,,,,,,,, 13.1.1,,,, 14.0.0,,,,,, 14.0.1, 14.1.0,

Fixed In:
15.0.0,,,, 12.1.4

Opened: Aug 09, 2018
Severity: 3-Major


A JavaScript whitepage challenge does not reconstruct when the challenge is on a POST request and the response from the back-end server is 307 Redirect. This happens only if the challenged URL is on a different path than the redirected URL. This prevents the application flow from completing.


Server is not able to parse the request payload and application does not work. This issue occurs because the TS*75 cookie is set on the path of the challenged URL, so the redirected URL does not contain the cookie, and the payload is not reconstructed properly to the server.


- JavaScript challenge / CAPTCHA is enabled from either Bot Defense, Proactive Bot Defense, Web Scraping, DoSL7 Mitigation or Brute Force Mitigation. - The challenge is happening on a POST request on which the response from the server is a 307 Redirect to a different path.


As a workaround, you can construct an iRule to identify that the response from the server is 307 Redirect, retrieve the TS*75 cookie from the request, and add to the response a Set-Cookie header, setting the TS*75 cookie on the '/' path.

Fix Information

Having a JavaScript challenge on a POST request with 307 Response no longer prevents the application from working.

Behavior Change