我已经写了支持请求的iOS团队。这里是他们回复的内容......实际上它与htpps有关......万一有人跑进了同样的错误，在这里可能是为什么的原因：瞄准一个只有当
我回答你的问题，为什么你的SOAP请求在iOS 7失败，而是你的两台服务器。你写道：
它可能与事实有关，一个服务器运行在https和 另一个运行在http？
事实证明，你的理论是正确的。这里的问题是iOS 7包含BEAST攻击的推荐对策。
http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack
http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html
https://www.imperialviolet.org/2012/01/15/beastfollowup.html
的iOS当它谈论到TLS 1.0或更早版本的服务器（TLS 1.1和更高版本包括对此次袭击自己修复）适用该措施是协商使用一个块密码（流密码不容易受到这种攻击）。
查看您发给我的测试应用程序的数据包跟踪，我可以看到它打开了一个到www.xxxx.xy：443的TLS 1.2连接。该服务器将连接降级到TLS 1.0，然后协商使用AES-128块密码（SSL_RSA_WITH_AES_128_CBC_SHA）。之后，我可以看到这种对抗措施无误的迹象。
我通过在模拟器上运行您的测试应用程序（它准确地再现了问题），然后使用调试器设置安全的内部状态Transport（在iOS上实现TLS的子系统）完全禁用此对策。在这样做，我发现你的应用程序的第一个标签工作正常。
这种对策的一个众所周知的副作用是它导致编写不佳的HTTPS服务器时出现问题。这是因为它将HTTP请求（通过TLS连接运行的请求）分解为块，并且必须对服务器进行编码以正确接收这些块并将它们连接到单个HTTP请求中。有些服务器没有正确执行，导致各种有趣的故障。
解决此问题的最佳方法是修复服务器。服务器应该能够应付接收组块的HTTP消息，在由RFC 2616
http://www.ietf.org/rfc/rfc2616.txt
如果修复太硬在短期内实现规定的方式检测HTTP消息边界，则只需升级服务器以支持TLS 1.2即可解决此问题。无论如何，这是个好主意。
另一个解决方法，一个不太好的主意是调整服务器配置，以协商使用流密码。
如果您不控制服务器，我强烈建议您游说服务器运营商以解决此问题的服务器端问题。 iOS 7不是唯一实施此解决方法的客户;您可以在最近的Chrome，Firefox等版本中找到它。
如果服务器端的修复是不可能的，你的客户端上的选项不是很理想：
o您可以用HTTP取代HTTPS。显然这不是一件好事，它也要求服务器支持HTTP。另外，HTTP带有一系列无趣的问题（各种中间件，尤其是那些由蜂窝运营商运行的中间件，就像使用HTTP消息一样）。
o在最低级别，您可以通过kSSLSessionOptionSendOneByteRecord标记（请参阅参考资料）为给定的安全传输上下文禁用此对策。虽然可以在CFSocketStream层使用该标志，但该标志不直接适用于更高级别的软件（因为该API为您提供了一种获取正在使用的安全传输上下文的方法）。
重要提示：高级API NSURLSession和NSURLConnection不允许您访问安全传输上下文，也不提供对TLS此方面的任何控制。因此，无法禁用这种对策并继续使用这些漂亮的高级API。
o您可以在我们的TLS基础设施（理想情况下为CFSocketStream）上实现您自己的HTTP层。唉，这是一个痛苦的世界：HTTP比你想像的要复杂得多。
对不起，我没有更好的消息。