About HTTP Response Pages
As part of access control, you can configure an HTTP response page to display when the system blocks web requests, using either access control rules or the access control policy default action.
The response page displayed depends on how you block the session:
Block Response Page: Overrides the default browser or server page that explains that the connection was denied.
Interactive Block Response Page: Warns users, but also allows them to click a button (or refresh the page) to load the originally requested site. Users may have to refresh after bypassing the response page to load page elements that did not load.
If you do not choose a response page, the system blocks sessions without interaction or explanation.
Limitations to HTTP Response Pages
Response Pages are for Access Control Rules/Default Action Only
The system displays a response page only for unencrypted or decrypted HTTP/HTTPS connections blocked (or interactively blocked) either by access control rules or by the access control policy default action. The system does not display a response page for connections blocked by any other policy or mechanism.
Displaying the Response Page Disables Connection Reset
The system cannot display a response page if the connection is reset (RST packet sent). If you enable response pages, the system prioritizes that configuration. Even if you choose Block with reset or Interactive Block with reset as the rule action, the system displays the response page and does not reset matching web connections. To ensure that blocked web connections reset, you must disable response pages.
Note that all non-web traffic that matches the rule is blocked with reset.
No Response Page for Encrypted Connections (Must Decrypt)
The system does not display a response page for encrypted connections blocked by access control rules (or any other configuration). Access control rules evaluate encrypted connections if you did not configure an SSL policy, or your SSL policy passes encrypted traffic.
For example, the system cannot decrypt HTTP/2 or SPDY sessions. If web traffic encrypted using one of these protocols reaches access control rule evaluation, the system does not display a response page if the session is blocked.
However, the system does display a response page for connections decrypted by the SSL policy, then blocked (or interactively blocked) either by access control rules or by the access control policy default action. In these cases, the system encrypts the response page and sends it at the end of the reencrypted SSL stream.
No Response Page for "Promoted" Connections
The system does not display a response page when web traffic is blocked as a result of a promoted access control rule (an early-placed blocking rule with only simple network conditions).
No Response Page for Certain Redirected Connections
If a URL is entered without specifying "http" or "https", and the browser initiates the connection on port 80, and the user clicks through a response page, and the connection is subsequently redirected to port 443, the user will not see a second interactive response page because the response to this URL is already cached.
No Response Page Before URL Identification
The system does not display a response page when web traffic is blocked before the system identifies the requested URL; see Best Practices for URL Filtering.
No Response Page with URL Category for Certain Devices
5506-X and 5508-X devices—whether managed by an FMC or using Adaptive Device Security Manager—do not display a response page if an access control rule using URL categories is matched TLS false start traffic. TLS false start traffic is defined by RFC 7918.