为什么.Net CF在调用HTTPS 的Web服务时失败

核心提示：因为.NetCF在解密收到的数据包后，返回给服务端的是一个空数据流(译者按：为什么要像这样返回呢，为什么.Net CF在调用HTTPS 的Web服务时失败(3)，我人为这就是文章开始提及的bug了吧，貌似我们很难从根本上解决)，英文很直接、很明白，往往到了中文这里却卡到阴，调用者会将这个返回的空数据流误认为是一个soc

因为.NetCF在解密收到的数据包后，返回给服务端的是一个空数据流(译者按：为什么要像这样返回呢，我人为这就是文章开始提及的bug了吧，貌似我们很难从根本上解决)，调用者会将这个返回的空数据流误认为是一个socket连接断开的信号，所以它也就终止了这一次和客户端的连接。

事实上，这就是在.NetCF程序中通过SSL调用Web Service时，收到空数据包响应的整个过程。结果就是在服务器响应前，连接就失败了，并且抛出一个异常信息。

那么，是什么导致了服务端传送这样的空加密数据包呢?技术上来说，是由于这些空数据包被允许进行传送(虽然它们毫无意义)，所以，这都看你的服务端如何配置，以确保这样的情况不会发生或极少发生。

但不幸的是，现在还没有办法让.NetCF去忽略这样的空数据包(译者按：我认为这里的.NetCF是指客户端程序)，所以，只有用如下的变通方法来解决了，从简单到复杂：

1、 不使用SSL进行请求(由于请求和响应采用明文，会产生安全隐患)

2、 重新配置现有的服务端程序，让其避免产生空加密数据包。

3、 Build a new web server that will forward your device's requests on a separate connection to the ultimate target server and forward the responses back to the device. This would work for web sites and web services. But this new front-end server (which serves something of the role of a proxy server) would have to be configured to not generate these empty encryption packets.

4、 [Added 1/2/08] Build a device-side web proxy that calls into the SSPI functions itself (native would probably be easier than managed for this). Then have your managed app call into the proxy. This proxy would be responsible for consuming the empty packets and re-encrypting everything (if necessary to secure IPC) for the app on the same device without any empty SSL packets.

5、 Wait until a future version of NetCF that fixes this bug.

6、 Write your own HTTPS client using native code or P/Invoke'ing from NetCF (difficult to get right).

翻译完!

哈哈，没想到吧，后几条Jack还是留给大家理解一下吧，感觉英语来的更直接!感觉时不时看看这些blogs很有帮助，在这里还是感谢Andarno为我们做出的贡献，虽然这是很早之前的问题了，希望这篇文章对大家有用。我会继续努力地。

很久没有看E文了，这篇文章其实光看、理解，只用了10多分钟，但是翻译却花了30多分钟，感觉很多时候，英文很直接、很明白，往往到了中文这里却卡到阴。我尽量把这个原因归咎于自己的中文词汇和专业知识不够吧。嘿嘿……

作者：Jack Fan(初学博闻 of .NET CF/.Net)

出处：http://longqi293.cnblogs.com