[Webkit-unassigned] [Bug 192926] New: Fails to load page when server returns 421 Misdirected

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Dec 20 03:40:06 PST 2018


https://bugs.webkit.org/show_bug.cgi?id=192926

            Bug ID: 192926
           Summary: Fails to load page when server returns 421 Misdirected
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Page Loading
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jddupas at xooloo.com
                CC: beidson at apple.com

When using HTTP/2, it is possible for a browser to reuse the same connection for different domains, if they all uses the same certificate and resolve to the same IP.

Some server (nains at least) do not support this when the web sites require user auth by certificate. They signal that to the user agent by properly returning a HTTP 421 status code.

According to HTTP/2 RFC:

   "A server that does not wish clients to reuse connections can indicate that it is not authoritative for a request by sending a 421 (Misdirected Request) status code in response to the request (see Section 9.1.2)."

On such error, the browser should retry the same request using a new connection.

    "Clients receiving a 421 (Misdirected Request) response from a server MAY retry the request – whether the request method is idempotent or not – over a different connection."

Actually, Safari Tech Preview just display an error page with the 421 status code.
In such case, the only reliable way to reach the target web site is to completely quit the browser to force closing all connection, and restart it.

This is not an acceptable behavior. If it does not retry the request using a new connection automatically, it should at least disable connection resume for this domain to force reopening a new connection at next attempt.


If it can help you to reproduce the problem, I found a reference of someone discussing this issue (with details about server config) here: https://awmanoj.github.io/tech/2017/02/05/421-misdirected-request-nginx/

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181220/927dfd53/attachment.html>


More information about the webkit-unassigned mailing list