我有一个非常具体的问题，我希望其他人遇到过。它只发生在装有iOS 10.3.3的iPad上。 我们在Windows Server 2016上的IIS中有一个ColdFusion网站，该网站拒绝在任何装有iOS 10.3.3的iPad上加载。当您尝试在 Safari 中打开网站时，它会旋转大约一分钟，然后说"Safari 无法打开页面，因为服务器停止响应"。
在 IIS 中，我们有一个类似于以下内容的 URL 重写规则：
<rule name="All files and directories that don't exist" enabled="true" patternSyntax="Wildcard" stopProcessing="true">
<match url="*/*" />
<conditions logicalGrouping="MatchAll" trackAllCaptures="true">
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
<add input="{REQUEST_FILENAME}" pattern="*CFIDE*" negate="true" />
</conditions>
<serverVariables>
<set name="NEW_SCRIPT_NAME" value="{R:0}" />
</serverVariables>
<action type="Rewrite" url="{R:2}?sub={R:1}" appendQueryString="true" logRewrittenUrl="false" />
</rule>
如果我在Chrome上访问该页面(再次使用相同的iPad)，则会出现相同的问题。
如果我使用 HTTP 而不是 HTTPS 在 iPad 上访问该页面，则重写规则将按预期工作，并且页面会呈现。
如果我禁用重写规则并在iPad上访问该页面，则该页面呈现良好。
如果我在具有较新(或较旧)iOS版本(例如5.1.1)的其他iPad上访问该页面，则该页面呈现良好。
我们在任何其他设备或浏览器上都没有遇到任何问题。所有其他设备(Android，Windows等)在我们测试过的所有浏览器上都可以按预期工作。
如果我查看IIS和ColdFusion日志，我可以看到来自iPad的请求，这几乎就像设备陷入了某种重定向循环，因为日志显示连续数百次请求同一页面。我们还尝试从不同的提供商处获取不同的SSL证书，也没有区别。
所以基本上，它似乎是3个元素的组合：SSL，Windows Server 2016和iOS 10.3.3上的IIS重写。消除或更改这 3 个元素中的任何一个都允许页面在我们的 iPad 上呈现，但不幸的是，消除或更改这 3 个元素中的任何一个对于我们的情况来说是不可行的。iOS 10.3.3 是可用于我们拥有的iPad的最新版本。
作为上下文，我们拥有的较旧的iPad之一在iOS 5.1.1上，它可以很好地呈现页面。
更新：我们尝试了另一台装有Windows Server 2012和IIS 6.2的服务器，它在iPad上按预期工作，因此Windows Server 2016也是变量之一。
另一个更新：使用在线浏览器模拟器，看起来问题存在于iOS 9.1到10.3上，而iOS <= 8.4和>= 11.0没有问题。在配置并触发 URL 重写规则的 Windows Server 2016 和 IIS 10.0 中，此问题很明显。
经过挖掘和挖掘，我发现这是一个与 IIS10 和 http/2 相关的已知问题。Adobe和Microsoft都参与其中，Microsoft应该在2018年4月发布修复程序。短期修复是禁用 http/2。我们的托管服务提供商还建议安装 BonCode 连接器作为修复程序。
请注意，这不仅会影响 url 重写，还会影响默认文档设置。
https://tracker.adobe.com/#/view/CF-4198446
更新：这是KB4093120的一部分修复
的https://support.microsoft.com/en-us/help/4093120/windows-10-update-kb4093120
我不知道为什么。该补丁没有解决我的问题(Windows Server 2016上的IIS 10)。最后，我需要关闭 IIS 中的 http2 .我在博客中写下了经验
http://dbwizard.blogspot.com/2020/10/iis-connects-to-tomcat-https-bug-in-iis.html