Bug 192926
| Summary: | Fails to load page when server returns 421 Misdirected | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Jean-Daniel <jddupas> |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | ap, beidson, cdumez |
| Priority: | P2 | ||
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Jean-Daniel
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/
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Chris Dumez
Sounds like a possible CFNetwork bug, not a WebKit bug. AFAIK we do not deal with HTTP2 at our layer.
Alexey Proskuryakov
Correct, this is tracked by Apple internally as rdar://problem/34187588. Thank you for the report! Marking as invalid since it's not an issue in WebKit code.