I need some guidance in troubleshooting an issue where a website hosted on a local IIS Server fails to load correctly on newer iPhone models (specifically, iPhone 12 Pro) using Chrome and Safari browsers. The website initially displays a blank page for a few seconds before showing an error message (as depicted in the image provided). This issue does not occur with older iPhones or on any other devices (computers, Android phones) which can access the site normally across various browsers.This phone have access to any other sites I assuming some DNS problems ...
The server logs do not reveal any errors, and websockets are functioning correctly. Our application is developed using .NET 8.0 and hosted with the ASP.NET Core Runtime 8.0.10 bundle in IIS. My Visual Studio is up to date with version 17.11.5.
As I have minimal experience with iPhones and limited familiarity with Blazor, I'm looking for initial steps or strategies to begin diagnosing this problem. I will soon have access to an iPhone from my IT department to conduct tests, but any preliminary guidance or insights would be greatly appreciated for troubleshooting. All devices are connected to the same WiFi network.
edited: The reason of this behaviour and how I fixed is in my last comment.
For the server part, please use IIS "Failed Request Tracing Module". While defining the tracing rule, on "Define Trace Conditions" page only "Time Taken(sec)" field should be entered with enough time to generate the condition that you are experiencing. The module will log the requests lasting for x sec or more. You may for ex. enter 5 sec if you get the above error after 5 or more seconds. Then regenerate the error to fill up trace logs on the disk.
By default C:\inetpub\logs\FailedReqLogFiles is the directory fills up with log files, one file per each request that the rule captures. You may find the more information about reading trace logs at:
In the trace logs, you may find the module on the IIS server which makes the application wait.
From the client side another useful tool will be curl tool or invoke-webrequest (powershell) cmdlet. They are similar tools that you can send a web request with a user agent such as Chrome, FireFox, Internet Explorer, Opera, and Safari or for curl curl -A "Agent 007" https://example.com (Ref: curl.se man page) As user agent you may input your application's related header information. With the trace option of the curl tool you can get detailed information about packets sent / received.
I suspect something related to TLS versions for example newer IOS will send TLS 1.3 requests which the server does not accept. In the curl trace you may find these details, this will show you whether the request is broken at the beginning during the TLS handshake.