HTTP error code 421 “Misdirected request” Resolution with Reverse Proxy
search cancel

HTTP error code 421 “Misdirected request” Resolution with Reverse Proxy

book

Article ID: 231564

calendar_today

Updated On:

Products

ASG-S400 ASG-S500

Issue/Introduction

Starting from 6.7.4.105, the ProxySG supports Server name Indication (SNI) in reverse proxy mode. Previously, SNI was supported for forward proxy only

SNI is used to indicate which hostname is being contacted by the browser at the beginning of the handshake process. This technology allows a server to serve several domains each with different SSL Certificates using the same IP address

Environment

6.7.5.14

 

Cause

Further checks show that the issue is mainly caused by complex configurations on the server side, as mentioned in the resolution section.

Resolution

For more details on the “Reverse Proxy” HTTP error code 421- Misdirected Request, we have referred to the below details.

Starting from 6.7.4.105, the proxysg supports Server name Indication (SNI) in reverse proxy mode. Previously, SNI was supported for forward proxy only

SNI is used to indicate which hostname is being contacted by the browser at the beginning of the handshake process. This technology allows a server to serve several domains each with different SSL Certificates using the same IP address

The user will get HTTP error code 421 “Misdirected request” when trying to connect to HTTPs page and all the below conditions occur at the same time:

  • Having Several vhosts on the same server/IP
  • Having redirection between these vhosts
  • Using different SSL certificate with different domain for each vhost
  • Using HTTP/1.1 or HTTP/2 which reuse the same SSL connection for several consequential HTTP requests
  • HTTP client; which is the proxy in this case; set the SNI in SSL handshake.

Further checks show that the issue is mainly caused by complex configurations on the server side, as mentioned above. So, it's recommended to separate any vhosts that have redirection on different servers/IP.

Note: With the above done, and the reported issue ever happens again, that would provide a confirmation of the bug discussed and the resolution would be the recommended upgrade to SGOS 7.2.2.1.

As a workaround, this issue can be solved by:
Disabling connection reuse on the proxy by setting http.server.persistence(no) for the vhost that response with HTTP redirection

For example, If example1.com redirects to example2.com; the below CPL script will be needed to not reuse the same SSL connection after redirection

<proxy>
  server_url.host=example1.com http.server.persistence(no)

Note that this workaround may cause high CPU/Memory utilization on customer servers if there’s a lot of connections on domain1.com as each single HTTP request has its SSL handshake.