我已经实现了类似的东西this唯一真正的区别是
string filename = context.Request.RawUrl.Replace("/", "\\").Remove(0,1);
string path = Uri.UnescapeDataString(Path.Combine(_baseFolder, filename));
这样我就可以遍历子目录。这对于网页和其他文本文件类型非常有用,但是当尝试提供媒体内容时,我遇到了例外
HttpListenerException:I/O
操作已中止,因为
线程退出或应用程序
要求
其次是
InvalidOperationException:在写入所有字节之前无法关闭流。
在使用语句中。
关于如何处理或停止这些异常有什么建议吗?
Thanks
我应该提到的是,我在浏览器中使用 Google Chrome(Google Chrome 似乎并不关心 MIME 类型,当它看到音频时,它会尝试像在 HTML5 播放器中一样使用它),但这也适用于以下情况您正在尝试在页面中托管媒体内容。
不管怎样,我用 fiddler 检查了我的 headers,并注意到 Chrome 向服务器传递了 3 个请求。我开始使用其他浏览器,发现它们没有这样做,但根据浏览器和我硬编码为 MIME 类型的内容,我要么得到一页疯狂的文本,要么下载文件。
经过进一步检查,我注意到 Chrome 会首先请求该文件。然后使用几个不同的标头再次请求该文件,尤其是范围标头。第一个字节=0 - 然后下一个具有不同的大小,具体取决于文件的大小(可以发出超过 3 个请求,具体取决于文件的大小)。
所以问题就来了。 Chrome 会首先请求该文件。一旦看到类型,它就会发送另一个请求,在我看来,该请求是在寻找文件有多大(字节=0-),然后另一个请求要求文件的后半部分或类似的东西,以允许使用时体验到一种流式传输HTML5。我快速编写了一些代码来处理 MIME 类型,并将 HTML5 页面与音频组件放在一起,发现其他浏览器也这样做(IE 除外)
所以这是一个快速解决方案,我不再收到这些错误
string range = context.Request.Headers["Range"];
int rangeBegin = 0;
int rangeEnd = msg.Length;
if (range != null)
{
string[] byteRange = range.Replace("bytes=", "").Split('-');
Int32.TryParse(byteRange[0], out rangeBegin);
if (byteRange.Length > 1 && !string.IsNullOrEmpty(byteRange[1]))
{
Int32.TryParse(byteRange[1], out rangeEnd);
}
}
context.Response.ContentLength64 = rangeEnd - rangeBegin;
using (Stream s = context.Response.OutputStream)
{
s.Write(msg, rangeBegin, rangeEnd - rangeBegin);
}
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)