当通过 Internet Explorer 使用 Windows Media Player 时，为什么有时无法在内容请求中包含适当的 cookie？
我们有一个托管在 IIS6 中的网站，该网站是使用 .NET 1.1 Framework 构建的。访问此站点的用户仅使用 Internet Explorer 并使用 Forms 身份验证登录。在网站内，用户可以导航到嵌入了 iFrame 的特定页面。该 iFrame 指向同一服务器上托管的另一个虚拟目录，而第二个虚拟目录只是向下传输电影文件。假设用户在其计算机上安装了 Windows Media Player 并将其配置为默认电影播放器，则当用户导航到带有 iFrame 的页面时，Windows Media Player 会弹出一个新窗口并播放电影。
我们最近升级了我们的软件以使用 .NET 3.5 框架。但是，我们注意到我们的电影文件不再播放。相反，我们收到一条消息，指示 Windows Media Player 无法连接到服务器。
我已经使用 Fiddler 对客户端和服务器计算机之间的网络流量进行了一些调查，这些是在工作场景中发生的步骤：
1) Internet Explorer 向服务器发出请求对于电影文件。请求标头包含正确身份验证和会话识别所需的 cookie。
*获取我的网站 HTTP/1.1
接受：image/jpeg、image/gif、image/pjpeg、application/x-ms-application、application/xaml+xml、application/x-ms-xbap、application/vnd.ms-excel、application/vnd.ms- powerpoint、application/msword、application/x-shockwave-flash、/
推荐人：MYREFERRER
接受语言：en-US
用户代理：Mozilla/4.0（兼容；MSIE 8.0；Windows NT 6.1；WOW64；Trident/4.0；SLCC2；.NET CLR 2.0.50727；.NET CLR 3.5.30729；.NET CLR 3.0.30729；InfoPath.2）
接受编码：gzip、deflate
主持人：我的主机 连接：保持活动
Cookie：a99fd71e-eb1b-4750-a391-5ad8cfe32068=800edb77-9649-4f93-9db9-98d678a3b166； ASP.NET_SessionId=uf1cr1bflwly0nmhbm1wnb55; EDDS=581A46E81C8DB0B475F1AFE00545F9B157A377BD31DF65BB2AEF7D1B293BDE9E178409FF251CF49F109FDC601C48F15A5FCDE1A29A18E6853357887698A01E7A2CC 3690ECE98C464DE1359D796B60BE969F875EF08F638A04CDED78A309ACD6E9732F8C3751A2B0A411ADFA91B0AE567*
2) 服务器使用cookies验证用户的请求，然后返回影片。返回的状态代码是 200。
HTTP/1.1 200 正常
日期：2010 年 8 月 11 日星期三 21:30:55 GMT
服务器：Microsoft-IIS/6.0
X-Powered-By：ASP.NET
X-AspNet-版本：1.1.4322
内容长度：3934146
接受范围：字节
内容配置：内联；文件名 = AS000006.wmv
最后修改时间：2010 年 8 月 10 日星期二 21:24:49 GMT
ETag：“我的示例文件 ID”
缓存控制：私有
Content-Type: application/octet-stream
3) Windows Media Player 向服务器请求电影文件。同样，请求标头包含 cookie。不过，这次请求包含字节 8192- 的 Range 请求。
*获取我的网站 HTTP/1.1
接受：/
用户代理：Windows-Media-Player/12.0.7600.16415
接受编码：gzip、deflate
范围：字节=8192-
除非修改自：2010 年 8 月 10 日星期二 21:24:49 GMT
如果范围：“MyExampleFileID”
连接：保持活动
主持人：MYHOST
Cookie：ASP.NET_SessionId=uf1cr1bflwly0nmhbm1wnb55； EDDS=581A46E81C8DB0B475F1AFE00545F9B157A377BD31DF65BB2AEF7D1B293BDE9E178409FF251CF49F109FDC601C48F15A5FCDE1A29A18E6853357887698A01E7A2CC 3690ECE98C464DE1359D796B60BE969F875EF08F638A04CDED78A309ACD6E9732F8C3751A2B0A411ADFA91B0AE567; a99fd71e-eb1b-4750-a391-5ad8cfe32068=800edb77-9649-4f93-9db9-98d678a3b166*
4) 服务器使用cookie信息来验证用户的请求，然后返回文档。返回的状态码是206。
HTTP/1.1 206 部分内容
日期：2010 年 8 月 11 日星期三 21:30:57 GMT
服务器：Microsoft-IIS/6.0
X-Powered-By：ASP.NET
X-AspNet-版本：1.1.4322
内容范围：字节8192-3934145/3934146
内容长度：3925954
接受范围：字节
内容配置：内联；文件名 = AS000006.wmv
最后修改时间：2010 年 8 月 10 日星期二 21:24:49 GMT
ETag：“我的示例文件 ID”
缓存控制：私有
Content-Type: application/octet-stream
当事情不起作用时，它看起来像这样：
1) Internet Explorer 向服务器发出电影文件的请求。请求标头包含cookie。
*获取我的网站 HTTP/1.1
接受：image/jpeg、image/gif、image/pjpeg、application/x-ms-application、application/xaml+xml、application/x-ms-xbap、application/vnd.ms-excel、application/vnd.ms- powerpoint、application/msword、application/x-shockwave-flash、/
推荐人：MYREFERRER 接受语言：en-US
用户代理：Mozilla/4.0（兼容；MSIE 8.0；Windows NT 6.1；WOW64；Trident/4.0；SLCC2；.NET CLR 2.0.50727；.NET CLR 3.5.30729；.NET CLR 3.0.30729；InfoPath.2）
接受编码：gzip、deflate
主持人：MYHOST
连接：保持活动
Cookie：a99fd71e-eb1b-4750-a391-5ad8cfe32068=7ac4710e-1434-43c9-b521-bdf30328e2fb； ASP.NET_SessionId=glytwo55ztohig451qrf1355; EDDS=CFC5EAE69F6D6CDD0A1D53632F01629F8AC8F4901A6106DD26A0A9F4E1E0B0EC9D4B1B78FBEF5C504A54E6B1A43F576CD846ADD3D394DF257EBBF982BED5E99900116945191268E985ED923DAA78DF4FBD68B09FF3B4D14D7092FB846012E5F464D9EBC4BA834235839A397A4F00B548D353A1AB9B67F6F960E26FC655D19D4B89347DFA2BCC7101E2397AC7EB0F105025E5A21253C0E619E809C1D9B64E53E8*
2) The server uses the cookies to authenticate the request from the user and then returns the movie.返回的状态代码是 200。
HTTP/1.1 200 正常
缓存控制：私有
内容长度：3934146
内容类型：应用程序/八位字节流
最后修改时间：2010 年 8 月 11 日星期三 15:29:44 GMT
接受范围：字节
ETag：“我的示例文件 ID”
服务器：Microsoft-IIS/7.5
X-AspNet-版本：2.0.50727
内容配置：内联；文件名 = AS000006.wmv
X-Powered-By：ASP.NET
日期：2010 年 8 月 11 日星期三 21:36:45 GMT
3) Windows Media Player 向服务器请求电影文件。该请求不包含任何cookie。服务器无法验证用户身份，电影也不会被发送。
*获取我的网站 HTTP/1.1
接受：/
用户代理：Windows-Media-Player/12.0.7600.16415
接受编码：gzip、deflate
范围：字节=8192-
除非修改自：2010 年 8 月 11 日星期三 15:29:44 GMT
如果范围：“MyExampleFileID”
连接：保持活动
主机：MYHOST*
所以，此时我确切地知道它不起作用的原因。来自 Windows Media Player 的请求不包含任何 cookie，因此我们的服务器不会验证该请求并发送数据。我完全无法理解的是，为什么 Windows Media Player 在发出请求时不使用这些 cookie。
上述所有请求都是从同一台计算机向两个不同的站点发出的，因此我知道这对于不同版本的 Windows Media Player 来说不是问题。我已经在具有不同操作系统和不同版本 IE 的几台不同计算机上重现了该行为，因此它似乎与特定计算机无关。我尝试恢复到 IIS6，而不是在新站点中使用 IIS7，但这也没有什么区别。我认为它必须是我的代码中的某些内容，但我什至不知道从哪里开始寻找。
我的问题是：是否有人真正了解 Internet Explorer 如何将 URL 信息传递到 Windows Media Player，并可能为我指明解决这个问题的正确方向？此时我唯一的其他选择是向 Microsoft 支持开具票证...坦率地说，在过去几年中，我与他们的支持团队的体验并不是最佳。任何帮助将不胜感激！
编辑： 使用进程资源管理器，我已经能够证明 IE 现在根本不向 Windows Media Player 提供 cookie 信息。不过，我仍然无法理解其中的原因。
We have a site hosted in IIS6 that we built using the .NET 1.1 Framework. Users who go to this site use Internet Explorer exclusively and log into it using Forms authentication. Within the site, users can navigate to a specific page that has an iFrame embedded in it. This iFrame points to another virtual directory hosted on the same server, and this second virtual directory simply streams down the movie file. Assuming the user has Windows Media Player installed on their machine and has configured it so that Windows Media Player is the default movie player, when a user navigates to the page with the iFrame, Windows Media Player pops open a new window and the movie plays.
We very recently upgraded our software to use the .NET 3.5 framework. However, we have noticed that our movie file no longer plays. We instead get a message indicating that Windows Media Player cannot connect to the server.
I've gone ahead and done some investigation of the network traffic between the client and server machines by using Fiddler, and these are the steps that happen in the scenario where things work:
1) Internet Explorer makes a request to the server for the movie file. The request header contains cookies that are required for proper authentication and session identification.
*GET MYSITE HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, /
Referer: MYREFERRER
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2)
Accept-Encoding: gzip, deflate
Host: MYHOST
Connection: Keep-Alive
Cookie: a99fd71e-eb1b-4750-a391-5ad8cfe32068=800edb77-9649-4f93-9db9-98d678a3b166; ASP.NET_SessionId=uf1cr1bflwly0nmhbm1wnb55; EDDS=581A46E81C8DB0B475F1AFE00545F9B157A377BD31DF65BB2AEF7D1B293BDE9E178409FF251CF49F109FDC601C48F15A5FCDE1A29A18E6853357887698A01E7A2CC3690ECE98C464DE1359D796B60BE969F875EF08F638A04CDED78A309ACD6E9732F8C3751A2B0A411ADFA91B0AE567*
2) The server uses the cookies to authenticate the request from the user and then returns the movie. The status code of the return is a 200.
HTTP/1.1 200 OK
Date: Wed, 11 Aug 2010 21:30:55 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Content-Length: 3934146
Accept-Ranges: bytes
Content-Disposition: inline; filename = AS000006.wmv
Last-Modified: Tue, 10 Aug 2010 21:24:49 GMT
ETag: "MyExampleFileID"
Cache-Control: private
Content-Type: application/octet-stream
3) Windows Media Player makes a request to the server for the movie file. Again, the request header contains cookies. However, this time the request includes a Range request for bytes 8192-.
*GET MYSITE HTTP/1.1
Accept: /
User-Agent: Windows-Media-Player/12.0.7600.16415
Accept-Encoding: gzip, deflate
Range: bytes=8192-
Unless-Modified-Since: Tue, 10 Aug 2010 21:24:49 GMT
If-Range: "MyExampleFileID"
Connection: Keep-Alive
Host: MYHOST
Cookie: ASP.NET_SessionId=uf1cr1bflwly0nmhbm1wnb55; EDDS=581A46E81C8DB0B475F1AFE00545F9B157A377BD31DF65BB2AEF7D1B293BDE9E178409FF251CF49F109FDC601C48F15A5FCDE1A29A18E6853357887698A01E7A2CC3690ECE98C464DE1359D796B60BE969F875EF08F638A04CDED78A309ACD6E9732F8C3751A2B0A411ADFA91B0AE567; a99fd71e-eb1b-4750-a391-5ad8cfe32068=800edb77-9649-4f93-9db9-98d678a3b166*
4) The server uses the cookie information to authenticate the request from the user and then returns the document. The status code of the return is a 206.
HTTP/1.1 206 Partial Content
Date: Wed, 11 Aug 2010 21:30:57 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Content-Range: bytes 8192-3934145/3934146
Content-Length: 3925954
Accept-Ranges: bytes
Content-Disposition: inline; filename = AS000006.wmv
Last-Modified: Tue, 10 Aug 2010 21:24:49 GMT
ETag: "MyExampleFileID"
Cache-Control: private
Content-Type: application/octet-stream
When things don't work, it looks like this:
1) Internet Explorer makes a request to the server for the movie file. The request header contains cookies.
*GET MYSITE HTTP/1.1
Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application, application/xaml+xml, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, /
Referer:MYREFERRER
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2)
Accept-Encoding: gzip, deflate
Host: MYHOST
Connection: Keep-Alive
Cookie: a99fd71e-eb1b-4750-a391-5ad8cfe32068=7ac4710e-1434-43c9-b521-bdf30328e2fb; ASP.NET_SessionId=glytwo55ztohig451qrf1355; EDDS=CFC5EAE69F6D6CDD0A1D53632F01629F8AC8F4901A6106DD26A0A9F4E1E0B0EC9D4B1B78FBEF5C504A54E6B1A43F576CD846ADD3D394DF257EBBF982BED5E99900116945191268E985ED923DAA78DF4FBD68B09FF3B4D14D7092FB846012E5F464D9EBC4BA834235839A397A4F00B548D353A1AB9B67F6F960E26FC655D19D4B89347DFA2BCC7101E2397AC7EB0F105025E5A21253C0E619E809C1D9B64E53E8*
2) The server uses the cookies to authenticate the request from the user and then returns the movie. The status code of the return is a 200.
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 3934146
Content-Type: application/octet-stream
Last-Modified: Wed, 11 Aug 2010 15:29:44 GMT
Accept-Ranges: bytes
ETag: "MyExampleFileID"
Server: Microsoft-IIS/7.5
X-AspNet-Version: 2.0.50727
Content-Disposition: inline; filename = AS000006.wmv
X-Powered-By: ASP.NET
Date: Wed, 11 Aug 2010 21:36:45 GMT
3) Windows Media Player makes a request to the server for the movie file. The request does NOT contain any cookies. The server fails to authenticate the user and the movie doesn't get sent down.
*GET MYSITE HTTP/1.1
Accept: /
User-Agent: Windows-Media-Player/12.0.7600.16415
Accept-Encoding: gzip, deflate
Range: bytes=8192-
Unless-Modified-Since: Wed, 11 Aug 2010 15:29:44 GMT
If-Range: "MyExampleFileID"
Connection: Keep-Alive
Host: MYHOST*
So, at this point I know exactly why it isn't working. The request from Windows Media Player doesn't contain any cookies, so our server won't authenticate the request and send down the data. What I'm completely failing to understand is why those cookies aren't being used by Windows Media Player when it makes it's request.
All of the above requests were made from the same machine to two different sites, so I know that it isn't an issue with different versions Windows Media Player. I've reproduced the behavior on several different machines with different operating systems and different versions of IE, so it doesn't appear to be related to a specific machine. I've tried reverting back to IIS6 instead of using IIS7 for the new site, and that doesn't make a difference either. I'm left thinking it has to be something in my code, but I don't even know where to begin looking.
My question is: Does anyone really understand how Internet Explorer passes URL information to Windows Media Player and perhaps point me in the right direction to figure this out? My only other option at this point is to open up a ticket with Microsoft support... and to be frank, my experience with their support team has been less than optimal over the past few years. Any help would be GREATLY appreciated!
EDIT:
Using process explorer, I've been able to prove that IE is simply not providing cookie information to Windows Media Player now. I'm still no closer to understanding why, though.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
经过几天与 Microsoft 的 4 位支持工程师进行故障排除后，我们并没有进一步了解该问题。然后，我团队中的一个人偶然发现了这个链接：
http://mvolo.com/iis-70-forms-authentication-and-embedded-media-players/
虽然文章中提到的错误消息不是我们看到的错误消息，但解决方案是提议引起了我的共鸣。我们尝试了一下，幸运的是，它解决了这个问题。
After days of troubleshooting with 4 support engineers from Microsoft, we were had been no closer to understanding the issue. Then, one of the guys on my team stumbled across this link:
http://mvolo.com/iis-70-forms-authentication-and-embedded-media-players/
While the error message mentioned in the article isn't the one we're seeing, the solution he proposed resonated with me. We gave it a shot, and thankfully, it solved the issue.