博客园_陋室铭

OAuth

2012-05-23T01:21:00Z

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要分享他们的访问许可或他们数据的所有内容。

OAuth是OpenID的一个补充，但是完全不同的服务。

本文链接

silverlight后台加载本地图片

2012-05-22T03:41:00Z

如果是resource
imgPuzzlePic.Source = new BitmapImage(new Uri("AD/AD.png", UriKind.Relative));

如果是content

imgPuzzlePic.Source = new BitmapImage(new Uri("/AD/AD.png", UriKind.Relative));

差别就是一个/

本文链接

Windows XPSP3通过网络级身份验证方式连接Windows Server 2008远程桌面

2012-05-21T01:25:00Z

远程桌面大大方便了大家的日常管理工作，Windows Server 2008同样秉承这一优秀特性，并引入网络级身份验证（NLA）作为远程桌面连接的默认身份验证方式。

网络级身份验证 (NLA) 是一种新的身份验证方法，在您建立所有远程桌面连接之前完成用户身份验证，并出现登录屏幕。这是最安全的身份验证方法，有助于保护远程计算机避免黑客或恶意软件的攻击。NLA 的优点：

1.最初需要较少的远程计算机资源。验证用户之前，远程计算机使用有限的资源，而不是像以前版本那样启动所有远程桌面连接。

2.可以通过减少拒绝服务攻击（试图限制或阻止访问 Internet）来帮助提供更高的安全。

3.使用远程计算机身份验证，从而帮助防止用户连接到设置为恶意目的的远程计算机。

查看计算机是否正在运行带 NLA 的远程桌面版本：

开始-运行-mstsc，打开“远程桌面连接”，单击左上角图标选择“关于”，如下图08是支持网络级别的身份验证的，而XP SP3默认不支持。

在使用XP通过远程桌面连接Server 2008远程桌面时会收到提示“远程计算机需要网络级身份验证，而您的计算机不支持该验证。请联系您的系统管理员或技术支持人员来获得帮助。”如下图：

要使XP通过远程桌面连接Server 2008，有两种办法：

1.修改Server 2008远程桌面连接方式为“允许运行任意版本远程桌面的计算机连接（较不安全）”。

2.修改XP注册表以支持使用NLA验证方式进行远程桌面连接。

开始-运行-regedit打开注册表编辑器。

定位到以下注册表键值：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa，双击右侧Security Packages，打开编辑多字符串对话框，在列表中添加 tspkg 。

定位到以下注册表键值：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders，双击右侧的SecurityProviders，打开编辑字符串对话框，在数值数据框中添加 , credssp.dll ，注意逗号后有一个英文的空格。

修改完成重启即可。

本文链接

WINDOWS 8

2012-05-20T13:04:00Z

WINDOWS 8最大的特点是“整合”，整合了PC、互联网和移动互联网。触摸屏的操控、云端的概念、app store、将主流网站的体验搬到系统、将社交网络整合到操作系统都让人眼前一亮。

1、WEB OS的雏形。较多内容放在“云端”。将来可以更好支持移动客户端。方便地整合google，twitter，flick等应用的内容。

2、更加注重社交网络。WIN8自带应用“人脉”，可以整合Google联系人、Twitter、Facebook、MSN通讯录等内容。

3、Metro整合了鼠标操作系统和触摸操作系统。UI很大程度模仿web、安卓或IOS的一些操控体验。

4、系统自带软件同步更新。尤其是加强了与微软其他产品如Bing、Mail，MSN、Xbox、Live的联系。

本文链接

经典力学、相对论、量子力学

2012-05-20T12:43:00Z

古老的牛顿力学城堡历经岁月磨砺风雨吹打而始终伟大和坚固，从天上的行星到地上的石块，万物都必恭必敬地遵循着它制定的规则，海王星的发现，就是它所取得的最伟大的胜利之一；在光学的方面，新的电磁理论把它的光荣扩大到了整个电磁世界；在热的方面，热力学三大定律、分子运动论和统计热力学灼灼生辉得让人不敢直视。

更令人惊奇的是，这一切都彼此相符而互相包容，形成了一个经典物理的大同盟。经典力学、经典电动力学和经典热力学（加上统计力学）形成了物理世界的三大支柱。它们紧紧地结合在一块儿，构筑起了一座华丽而雄伟的殿堂。

“这个世界所有的基本原理都已经被发现了！只要拥有足够详细的数据，不管是明天的天气还是一亿年以后宇宙的形态，人类都可以分毫不差的计算出来！”

量子物理学的破坏力是相当惊人的。在概率解释，不确定性原理和互补原理这三大核心原理中，前两者摧毁了经典世界的因果性，互补原理和不确定原理又合力捣毁了世界的客观性和实在性。

天气永远不可能被预知，宇宙也在每一秒都随机呈现出不同的形态……

越是深入学习，越是觉得，不仅真理在远离自己而去，甚至原本客观真实存在的世界都渐渐变得支离破碎。　

经典力学等等，其实是从现象上总结世界的规律，量子物理学，应该已经开始从本质上解析这个世界了。所以一个是“预测”，一个是“预言”。

翻译成编程思想就是：

经典力学等等：是系统本身的功能，可以通过掌握所有功能“预测”未来。

量子物理学：源代码，可以通过掌握源代码“预言”为了，甚至可以直接修改源代码，改变微观概率，来改变世界原本的形态。

本文链接

英雄每多屠狗辈，自古侠女出风尘(看黄金大劫案有感)

2012-05-19T15:42:00Z

英雄每多屠狗辈，自古侠女出风尘

本文链接

展现、通讯、IO

2012-05-19T12:02:00Z

应用程序最基础的就是：展现、通讯、IO

展现：比如界面呈现，drawing等等

通讯：http,tcp/ip,Socket,WCF,Webservices等等

IO：输入输出，文件操作，计算机控制等等。

而新出一个技术平台，我最喜欢先研究的是通信技术，我认为通信技术清楚了，这个设计结构就清楚了，至于展现和IO其实和其他技术区别不会大，至少结构区别不大。

本文链接

WP7应用开发笔记(5) 通信设计

2012-05-19T11:55:00Z

WP7支持的通信方式

1. HTTP协议

主要是由WebClient或HttpWebRequest两个类提供，直接封装HTTP协议访问Web站点。最常用的通信方式。

2. WCF

WCF作为MS大力推广的通信方案非常强大，但是到了WP7上就变成了太监，只支持简单的BasicHttpBinding而且还有非常多的限制。

3 Socket

7.1SDK里新增的通信方式，支持TCP和UDP但只能使用异步的SocketAsyncEventArgs事件方式，也有不少限制。

选择通信方式

因为同时需要考虑到服务器端的实现，在服务器端尽量精简，最好不要有什么IIS之类大型依赖。

对应是服务器端实现方式如下：

HTTP协议	HttpListener
WCF	Wcf应用程序宿主
Socket	Socket

由于我使用的是Win7 HttpListener和BasicHttpBinding在监听外网IP时都需要管理员身份验证，这点很不友好，我每次开程序都提示一下，不爽。所以决定使用Socket。

SOCKET协议选择

而Socket分为TCP和UDP，为了稳定选择了有重传功能和回复的TCP（其实UDP也不是什么问题）。

TCP需要3次握手来维持链接，但是按照“偶尔连接”(Occasionally Connect)的设计准则，我不能让手机一直保持连接，而且断线检查也是个麻烦事。

所以决定采用HTTP1.0类似的短链接方式，就是连上、发一条消息、然后断开的流程（暂时没有回复）

应用层消息报文设计

这个程序比较简单设计的报文也很简单，

因为内网传输不需要考虑身份验证，加密、完整性等，而且短链接不会遇到粘包和拆包之类的，真是太轻松了。

报文结构如下

Length	长度	4字节 int
Action	动作	32字节 UTF8编码
Context	内容	长度由Length描述 UTF8编码

Length表示Context的长度，报文本身长度为Length+4+32

Action目前只有”TAP”按键一种

Context表示按键的类型有2种分类

一种是 Keyboard 直接对应键盘的键名称
另一种是 Media 媒体控制用包括TogglePlayPause（播放暂停）、Forward（前进）、Backward（后退）IncreaseVolume（提高音量）等

表示方式是“Media.TogglePlayPause”

Media 协议表

namespace VirtualKeyboard.Contract
{
public static class KeyMethods
{
public const string KeyboardPackage = "Keyboard";
public const string MediaPackage = "Media";

public static class Keyboard
{
private const string KeyboardPre = KeyboardPackage + ".";

/// <summary>
/// Enter
/// </summary>
public const string Enter = KeyboardPre + "Enter";

/// <summary>
/// Esc
/// </summary>
public const string Esc = KeyboardPre + "Esc";
}

public static class Media
{
private const string MediaPre = MediaPackage + ".";

/// <summary>
/// 切换播放暂停
/// </summary>
public const string TogglePlayPause = MediaPre + "TogglePlayPause";

/// <summary>
/// 快进
/// </summary>
public const string FastForward = MediaPre + "FastForward";

/// <summary>
/// 快退
/// </summary>
public const string FastBackward = MediaPre + "FastBackward";

/// <summary>
/// 大步快进
/// </summary>
public const string VeryFastForward = MediaPre + "VeryFastForward";

/// <summary>
/// 大步快退
/// </summary>
public const string VeryFastBackward = MediaPre + "VeryFastBackward";

/// <summary>
/// 前进
/// </summary>
public const string Forward = MediaPre + "Forward";

/// <summary>
/// 前退
/// </summary>
public const string Backward = MediaPre + "Backward";

/// <summary>
/// 提高音量
/// </summary>
public const string IncreaseVolume = MediaPre + "IncreaseVolume";

/// <summary>
/// 降低音量
/// </summary>
public const string DecreaseVolume = MediaPre + "DecreaseVolume";

/// <summary>
/// 静音
/// </summary>
public const string MuteVolume = MediaPre + "MuteVolume";

/// <summary>
/// 上一集
/// </summary>
public const string PreviousTrack = MediaPre + "PreviousTrack";

/// <summary>
/// 下一集
/// </summary>
public const string NextTrack = MediaPre + "NextTrack ";

/// <summary>
/// 停止
/// </summary>
public const string Stop = MediaPre + "Stop";

/// <summary>
/// 全屏
/// </summary>
public const string FullScreen = MediaPre + "FullScreen";
}
}
}

客户端通信代码实现

public class SendCommandCompletedEventArgs : EventArgs
{
public bool Success { get; internal set; }
public string ErrMessage { get; internal set; }
}

public class Client
{
const int ActionSize = 32;
const int BufferSize = 1024;

public event EventHandler<SendCommandCompletedEventArgs> SendCommandCompleted;

private void OnSendCommandCompleted(SendCommandCompletedEventArgs e)
{
EventHandler<SendCommandCompletedEventArgs> handler = SendCommandCompleted;
if (handler != null) handler(this, e);
}

public Client()
{

}

public void SendCommandAsync(EndPoint endPoint, string action, string command)
{
var actionBuffer = Encoding.UTF8.GetBytes(action);
var contextBuffer = Encoding.UTF8.GetBytes(command);

var bufferSize = contextBuffer.Length + ActionSize + 4;
var lengthBuffer = BitConverter.GetBytes(contextBuffer.Length);

var buffer = new byte[BufferSize];
int offset = 0;
Array.Copy(lengthBuffer, 0, buffer, offset, lengthBuffer.Length);
offset += 4;
Array.Clear(buffer, offset, ActionSize);
Array.Copy(actionBuffer, 0, buffer, offset, actionBuffer.Length);
offset += ActionSize;
Array.Copy(contextBuffer, 0, buffer, offset, contextBuffer.Length);

var socketAsyncEventArgs = new SocketAsyncEventArgs
{
UserToken =
new Socket(AddressFamily.InterNetwork, SocketType.Stream,
ProtocolType.Tcp)
};
socketAsyncEventArgs.Completed += AsyncCompleted;
socketAsyncEventArgs.SetBuffer(buffer, 0, bufferSize);
socketAsyncEventArgs.RemoteEndPoint = endPoint;
ProcessConnect(socketAsyncEventArgs);
}

#region Private
private void ProcessConnect(SocketAsyncEventArgs e)
{
var socket = (Socket)e.UserToken;
bool willRaiseEvent = socket.ConnectAsync(e);
if (!willRaiseEvent)
{
ConnectCompleted(e);
}
}

private void ProcessSend(SocketAsyncEventArgs e)
{
var socket = (Socket)e.UserToken;
bool willRaiseEvent = socket.SendAsync(e);
if (!willRaiseEvent)
{
SendCompleted(e);
}
}

private void AsyncCompleted(object sender, SocketAsyncEventArgs e)
{
switch (e.LastOperation)
{
case SocketAsyncOperation.Connect:
ConnectCompleted(e);
break;
case SocketAsyncOperation.Send:
SendCompleted(e);
break;
case SocketAsyncOperation.Receive:
ReceiveCompleted(e);
break;
default:
return;
}

}

private void ReceiveCompleted(SocketAsyncEventArgs e)
{
}
private void ConnectCompleted(SocketAsyncEventArgs e)
{
if (e.SocketError == SocketError.Success)
{
ProcessSend(e);
}
else
{
OnSendCommandCompleted(new SendCommandCompletedEventArgs { Success = false, ErrMessage = "接收器无法连接" });
}
}

private void SendCompleted(SocketAsyncEventArgs e)
{
var socket = (Socket)e.UserToken;
socket.Close();
if (e.SocketError == SocketError.Success)
{
OnSendCommandCompleted(new SendCommandCompletedEventArgs { Success = true });
}
else
{
OnSendCommandCompleted(new SendCommandCompletedEventArgs { Success = false, ErrMessage = "发送命令失败" });
}

}
#endregion

}

转自：http://www.cnblogs.com/kiminozo/archive/2012/01/25/2329384.html

本文链接

你需要权限才能执行此操作

2012-05-18T14:54:00Z

想删除一个文件分明是Administrator用户却提示不允许，点击右键安全才发现只有eyeryone权限并且没有修改权限，原来是创建程序为了不允许删除，权限赋少了，把可修改权限给了就可以删除了。

打开这个软件的根文件夹，右键，选择属性，在安全选项卡下，找到你的用户名，如果你不知道那个是，干脆所有的用户名都给它打上全部控制的权限，OK。

本文链接

在ASP.NET中跟踪和恢复大文件下载

2012-05-14T18:11:00Z

在Web应用程序中处理大文件下载的问题一直出了名的困难，因此对于大多数站点来说，如果用户的下载被中断了，它们只能说悲哀降临到用户的身上了。但是我们现在不必这样了，因为你可以使自己的ASP.NET应用程序有能力支持可恢复（继续）的大文件下载。使用本文提供的方法的时候，你可以跟踪下载的过程，这样你就可以处理动态建立的文件--而且要达到这个目标根本不需要旧式的ISAPI动态链接库和非受控的（unmanaged）C++代码。

为客户端提供从互联网上下载文件的服务最容易了，对吗？仅仅只需要把可下载的文件复制到你的Web应用程序目录中，发布链接并让IIS完成所有相关的工作。但是，文件服务不应该比脖子上的疼痛还要多（还要麻烦），你不希望整个世界都能访问自己的数据，你不希望服务器被数百个静态文件塞满了，你甚至于希望下载临时文件--只有当客户端开始下载后的空闲时间才建立这些文件。

不幸的是，使用IIS对下载请求的默认的响应是不可能达到这些效果的。因此在一般情况下，为了获得对下载过程的控制权，开发者需要链接到一个定制的.aspx页面，在这个页面中它们检查用户凭证（credential）、建立可以下载的文件并使用下面的代码把该文件推送给客户端：

Response.WriteFile
Response.End()

而这就是出现真正麻烦的地方。

有什么问题？

WriteFile方法看起来非常完美，它使文件的二进制数据流向客户端。但是直到最近我们才知道，WriteFile方法是一个出名的内存占用狂，它把整个文件载入服务器的RAM中来提供服务（实际上它甚至于会占用文件两倍大小的空间）。对于大文件，这会引起服务内存问题，并且可能重复ASP.NET过程。但是在2004年6月微软发布了一个补丁解决了这个问题。这个补丁现在是.NET Framework 1.1补丁包（SP1）的一部分。

这个补丁引入了TransmitFile方法，它把一个磁盘文件读入到较小的内存缓冲区之后就开始传输该文件。尽管这个方案解决了内存和循环的问题，但是它仍然不能令人满意。你不能控制响应的生命周期。你无法知道下载是否正确地完成了，你没有办法知道下载是否被中断了，并且（如果你建立了临时文件）你也不知道是否应该、以及什么时候可以删除这些文件。更糟的是，如果下载的确失败了，TransmitFile方法又从客户端下次尝试的文件头部开始下载。

其中一种可能的解决方案--实现后台智能传输服务（BITS）对于多数站点来说是不可行的，因为这会毁掉维持客户端浏览器和操作系统独立性而作出的努力。

令人满意的解决方案的基础还是来自微软用于解决WriteFile引起的内存混乱问题的第一次尝试（见知识库文章812406）。那篇文章演示了智能的大块数据下载过程，它从文件流中读取数据。在服务器把字节块发送给客户端之前，它使用Response.IsClientConnected属性检查客户端是否仍然保持着连接。如果仍然保持连接，它就继续发送流字节，否则就停止，以防止服务器发送不必要的数据。
这就是我们采用的方法，特别是在下载临时文件的时候。在IsClientConnected返回False的情况下，你就知道下载过程被中断了，你应该保存文件；反之，当这个过程成功完成的时候，你就删除临时文件。此外，为了恢复中断了的下载，你需要做的工作是从上次下载尝试过程中客户端连接失败的文件点开始下载。

HTTP协议和头信息（Header）支持

HTTP协议支持可以用于处理被中断下载的头信息。使用少量的HTTP头信息，你可以增强自己的下载过程，使它完全遵循HTTP协议规范。这个规范与ranges一起提供恢复被中断的下载所需要的一切信息。

下面是它的工作方式。首先，如果服务器支持客户端断点续传，它就在初始的响应中发送Accept-Ranges头信息。服务器还发送一个实体标签（entity tag）头信息（ETag），它包含一个唯一的标识字符串。

下面的代码显示了IIS发送给客户端的用于响应一个初始下载请求的一些头信息，它向客户端传递了被请求的文件的详细信息。

HTTP/1.1 200 OK
Connection: close
Date: Tue, 19 Oct 2004 15:11:23 GMT
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "47febb2cfd76c41:2062"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2844011

在接收这些头信息之后，如果下载被中断了，IE浏览器在后来的下载请求中会把Etag值和Range头信息发送回服务器。下面的代码显示了尝试恢复被中断下载时IE发送给服务器的一些头信息。

GET http://192.168.100.100/download.zip HTTP/1.0
Range: bytes=822603-
Unless-Modified-Since: Sun, 26 Sep 2004 15:52:45 GMT
If-Range: "47febb2cfd76c41:2062"

这些头信息表明IE缓存了IIS提供的实体标签，并在If-Range头信息中把它发送回服务器了，这是确保下载从准确相同的文件恢复的一种途径。不幸的是，并非所有的浏览器的工作方式都相同。客户端发送的用于验证文件的其它HTTP头信息可能是If-Match、If-Unmodified-Since或者Unless-Modified-Since。很明显，该规范对于客户端软件必须支持哪些头信息，或者必须使用哪些头信息没有明确的规定。因此，有些客户端根本就没有使用头信息，而IE只使用If-Range和Unless-Modified-Since。你最好用代码检查这些信息。采用这种方式的时候，你的应用程序可以在非常高的层次遵循HTTP规范，并可以使用多种浏览器。Range头信息指明了被请求的字节范围--在例子中它是服务器应该恢复文件流的起始点。

当IIS接收到恢复下载的请求类型时，它发回包含下面的头信息的响应信息：

HTTP/1.1 206 Partial Content
Content-Range: bytes 822603-2844010/2844011
Accept-Ranges: bytes
Last-Modified: Sun, 26 Sep 2004 15:52:45 GMT
ETag: "47febb2cfd76c41:2062"
Cache-Control: private
Content-Type: application/x-zip-compressed
Content-Length: 2021408

请注意上面的代码与最初的下载请求的HTTP响应有点差别--恢复下载的请求是206而最初下载的请求是200。这表明通过线路传递进来的内容是部分文件。这一次Content-Range头信息指出了被传递字节的精确数量和位置。

IE对于这些头信息是很挑剔的。如果最初的响应没有包含Etag头信息，IE永远不会尝试恢复下载。我测试过的其它客户端不使用ETag头信息，它们简单得依赖于文件名、请求范围，并使用Last-Modified头信息（如果它们试图验证该文件）。

深入了解HTTP协议

前面的部分中显示的头信息对于使恢复下载的解决方案运行来说是足够的，但是它没有完全覆盖HTTP规范。

在单个请求中，Range头信息可以询问多个范围，这种特性称为"多部分范围（multipart ranges）"。请不要与分段下载（segmented downloading）混淆，几乎所有的下载工具都使用分段下载来提高下载速度。这些工具声称通过打开两个或多个并发的连接（每个连接请求文件的不同范围）提高了下载速度。

多部分范围的想法并没有开启多个连接，但是它可以使客户端软件可以在单个请求/响应周期中请求某个文件的最前面的十个和最后面的十个字节。

诚实地说，我从来都没有找到使用这种特性软件片断。但是我拒绝在代码声明中写入"它并不是完全的HTTP兼容的"。略去这个特性必定会触犯墨菲法则（Murphy's Law）。无论如何，多部分范围还是被用于电子邮件传输中，把头信息、普通文本和附件分开。

示例代码

我们知道了客户端和服务器如何交换头信息以保证可恢复的下载，把这些知识与文件块流的思想结合起来，你就可以给自己的ASP.NET应用程序增加可靠的下载管理能力了。

获取下载过程的控制权的方法是从客户端截取下载请求、读取头信息并适当地响应。在.NET之前，你必须编写ISAPI（Internet服务器API）应用程序来实现这种功能，但是.NET框架组件提供了一个IHttpHandler接口，在类中实现的时候，它允许你仅仅使用.NET代码就能够截取和处理请求。这意味着你的应用程序对于下载过程有完全控制权和响应性，再也不会涉及或使用IIS的自动化函数。

示例代码在HttpHandler.vb文件中包含了一个自定义的HttpHandler类（ZIPHandler）。ZipHandler实现了IhttpHandler接口，并且处理对所有.zip文件的请求。

为了测试示例代码，你需要在IIS中建立一个新的虚拟目录，并把源文件复制到那儿。在该目录中建立一个叫做download.zip的文件（请注意IIS和ASP.NET不能处理大于2GB的下载，因此要确保你的文件没有超过该限制）。配置你的IIS虚拟目录，通过aspnet_isapi.dll映射.zip扩展名。

HttpHandler类：ZIPHandler

在ASP.NET中映射了.zip扩展名之后，客户端每次向服务器请求.zip文件的时候，IIS调用ZipHandler类的ProcessRequest方法（见下载代码）。

ProcessRequest方法首先建立自定义的FileInformation类（见下载代码）的一个实例，它封装了下载的状态（例如进行中、被中断了等等）。示例把download.zip示例文件的路径硬编码到代码中了。如果把这段代码应用于你自己的应用程序，需要修改它来打开被请求的文件。

' 使用objRequest检测请求了哪个文件，用该文件打开objFile。
' 例如objFile = New Download.FileInformation(<完整文件名>)
objFile = New Download.FileInformation( _
objContext.Server.MapPath("~/download.zip"))

接下来，程序使用描述的HTTP头信息（如果请求提供了头信息）执行一系列的验证检查。它把每种检查都封装在小型私有函数中，如果验证成功的话就返回True。如果某个验证检查失败了，响应会立即终止，并发送适当的StatusCode值。

If Not objRequest.HttpMethod.Equals(HTTP_METHOD_GET) Or Not
objRequest.HttpMethod.Equals(HTTP_METHOD_HEAD) Then
　' 目前只支持GET和HEAD方法
　objResponse.StatusCode = 501 ' 没有执行
ElseIf Not objFile.Exists Then
　' 无法找到被请求的文件
　objResponse.StatusCode = 404 ' 没有找到
ElseIf objFile.Length > Int32.MaxValue Then
　' 文件太大了
　objResponse.StatusCode = 413 ' 请求实体太大
ElseIf Not ParseRequestHeaderRange(objRequest, alRequestedRangesBegin, alRequestedRangesend, _
objFile.Length, bIsRangeRequest) Then
　' Range请求中包含无用的实体
　objResponse.StatusCode = 400 ' 无用的请求
ElseIf Not CheckIfModifiedSince(objRequest,objFile) Then
　' 实体没有被修改过
　objResponse.StatusCode = 304 ' 没有被修改过
ElseIf Not CheckIfUnmodifiedSince(objRequest,objFile) Then
　' 实体在上次被请求的日期之后被修改过
　objResponse.StatusCode = 412 ' 预处理失败
ElseIf Not CheckIfMatch(objRequest, objFile) Then
　' 实体与请求不匹配
　objResponse.StatusCode = 412 ' 预处理失败
ElseIf Not CheckIfNoneMatch(objRequest, objResponse,objFile) Then
　' 实体的确与none-match请求匹配。
　' 响应代码位于CheckIfNoneMatch函数中
Else
　' 初步检查成功

这些初步检查的函数中的ParseRequestHeaderRange（见下载代码）检查客户端是否请求了文件范围（这意味着是一个局部下载）。如果被请求的范围是无效的（无效范围指超越文件大小或包含不合理数字的范围数值），该方法把bIsRangeRequest设置为True。如果请求了范围，CheckIfRange方法会验证IfRange头信息。

如果被请求的范围是有效的，代码会计算响应信息的大小。如果客户端请求了多个范围，响应信息大小的数值会包含多部分头部信息长度的数值。

如果不能确定某个发送的头部信息值，程序将把这个下载请求作为最初请求而不是部分下载来处理，从文件的顶部开始发送一个新的下载流。

If bIsRangeRequest AndAlso CheckIfRange(objRequest, objFile) Then
　' 这是范围请求
　' 如果Range数组包含多个实体，它还是一个多部分范围请求
　bMultipart = CBool(alRequestedRangesBegin.GetUpperBound(0)>0)
　' 进入每个范围来获取整个响应长度
　For iLoop = alRequestedRangesBegin.GetLowerBound(0) To alRequestedRangesBegin.GetUpperBound(0)
' 内容的长度(这个范围的)
iResponseContentLength += Convert.ToInt32(alRequestedRangesend( _
iLoop) - alRequestedRangesBegin(iLoop)) + 1
If bMultipart Then
　' 如果是多部分范围请求，计算出将发送的中间头信息的长度
　iResponseContentLength += MULTIPART_BOUNDARY.Length
　iResponseContentLength += objFile.ContentType.Length
　iResponseContentLength += alRequestedRangesBegin(iLoop).ToString.Length
　iResponseContentLength += alRequestedRangesend(iLoop).ToString.Length
　iResponseContentLength += objFile.Length.ToString.Length
　' 49是多部分下载中换行和其它必要的字符的长度
　iResponseContentLength += 49
End If
　Next iLoop

　If bMultipart Then
' 如果是多部分范围请求，
' 我们还必须计算出将发送的最后一个中间头信息的长度
iResponseContentLength +=MULTIPART_BOUNDARY.Length
' 8 是破折号和换行符的长度
iResponseContentLength += 8
　Else
' 不是多部分下载，因此我们必须说明初始HTTP头信息的响应范围
objResponse.AppendHeader( HTTP_HEADER_CONTENT_RANGE, "bytes " & _
alRequestedRangesBegin(0).ToString & "-" & _
alRequestedRangesend(0).ToString & "/" & _
objFile.Length.ToString)
'End If
' 范围响应
objResponse.StatusCode = 206 ' 局部响应
　Else
' 这不是范围请求，或者被请求的范围实体ID与当前的实体ID不匹配，
' 因此开始新的下载
' 指明文件完成部分的大小等于内容的长度
iResponseContentLength =Convert.ToInt32(objFile.Length)
' 返回正常的OK状态
objResponse.StatusCode = 200
　End If
　' 接下来服务器必须发送几个重要的响应头信息，例如内容长度、Etag、和文件的内容类型：
　' 把内容长度写入响应
　objResponse.AppendHeader( HTTP_HEADER_CONTENT_LENGTH,iResponseContentLength.ToString)
　' 把最后修改日期写入响应
　objResponse.AppendHeader( HTTP_HEADER_LAST_MODIFIED,objFile.LastWriteTimeUTC.ToString("r"))
　' 告诉客户端软件我们接受了范围请求
　objResponse.AppendHeader( HTTP_HEADER_ACCEPT_RANGES,HTTP_HEADER_ACCEPT_RANGES_BYTES)
　' 把文件的实体标签写入响应（用引号括起来）
　objResponse.AppendHeader(HTTP_HEADER_ENTITY_TAG, """" & objFile.EntityTag & """")
　' 把内容类型写入响应
　If bMultipart Then
' 多部分消息有这种特殊的类型
' 在例子中文件实际的mime类型在以后才写入响应
objResponse.ContentType = MULTIPART_CONTENTTYPE
　Else
' 单个部分消息拥有的文件内容类型
objResponse.ContentType = objFile.ContentType
End If

下载所需要的一切都准备好了，可以开始下载文件了。你将使用FileStream对象从文件中读取字节块。把FileInformation实例objFile的State属性设置为fsDownloadInProgress。只要客户端保持连接，服务器就从文件中读取字节块并发送给客户端。对于多部分下载，这段代码会发送特定的头信息。如果客户端中断连接，服务器就把文件状态设置为fsDownloadBroken。如果服务器完成了被请求范围的发送过程，它会把状态设置为fsDownloadFinished（见下载代码）。

FileInformation辅助类

在ZIPHandler部分中你会发现，FileInformation是一个辅助类，它封装了下载状态信息（例如下载中、中断等等）。

为了建立FileInformation的实例，你需要把被请求文件的路径传递给该类的构造函数：

Public Sub New(ByVal sPath As String)
　m_objFile = New System.IO.FileInfo(sPath)
End Sub

FileInformation使用System.IO.FileInfo对象来获取文件的信息，这些信息是作为该对象的属性暴露的（例如文件是否存在、文件全名、大小等等）。这个类还暴露了一个DownloadState枚举，它描述了下载请求的多种状态：

Enum DownloadState
　' Clear：没有下载过程，文件可能在维护
　fsClear = 1
　' Locked：动态建立的文件不能被更改
　fsLocked = 2
　' In Progress：文件被锁定了，下载过程正在进行
　fsDownloadInProgress = 6
　' Broken：文件被锁定了，下载过程正在进行，但是被取消了
　fsDownloadBroken = 10
　' Finished：文件被锁定了，下载过程完成了
　fsDownloadFinished = 18
End Enum

FileInformation还提供了EntityTag属性值。示例代码中的这个值是硬编码的，这是由于示例代码只使用了一个下载文件，并且该文件不会被改变，但是对于实际应用程序来说，你会提供多个文件，甚至于动态地建立文件，你的代码必须为每个文件提供一个唯一的EntityTag值。此外，每次改变或修改该文件的时候，这个值也必须改变。这使客户端软件能够验证它们已经下载的字节块是否仍然是最新的。下面是示例代码中返回硬编码EntityTag值的部分：

Public ReadOnly Property EntityTag() As String
　' EntityTag用于对客户端的初始（200）响应，以及来自客户端的恢复请求
　Get
' 为文件建立唯一的字符串。
' 注意，只要文件没有发生改变，该唯一码就必须保留。
' 但是，如果文件的确改变了或者被修改了，这个码必须改变。
Return "MyExampleFileID"
　End Get
End Property

一个简单的和大致足够安全的EntityTag可能由文件名和文件最后被修改的日期组成。无论使用什么方法，你都必须确保这个值是真的是唯一的，不会与其它文件的EntityTag混淆。我希望在自己的应用程序中按照客户、顾客和邮编索引来动态地替被建立的文件命名，并把用作EntityTag的GUID存储在数据库中。

ZipFileHandler类读取和设置公共的State属性。在完成下载以后，它把State设置为fsDownloadFinished。这个时候你就可以删除临时文件了。这儿一般需要调用Save方法来维持状态。

Public Property State() As DownloadState
　Get
Return m_nState
　End Get
　Set(ByVal nState As DownloadState)
m_nState = nState
' 可选操作：这个时候你可以自动地删除文件。
' 如果状态被设置为Finished ，你就再也不需要这个文件了。
' If nState =DownloadState.fsDownloadFinished Then
　' Clear()
' Else
　' Save()
' End If
Save()
　End Set
End Property

在文件状态发生改变的任何时候ZipFileHandler都应该调用Save方法，保存文件的状态，这样在以后才能显示给用户。你还可以用它来保存你自己建立的EntityTag。请不要把文件的状态和EntityTag值保存在Application、Session或Cache中--你必须跨越所有的这些这些对象的生命周期来保存信息。

Private Sub Save()
　' 把该文件下载的状态保存到数据库或XML文件中。
　' 当然，如果你并没有动态地建立文件，就不需要保存这个状态。
End Sub

前面提到，示例代码只处理一个已有的文件（download.zip），但是你可以进一步增强这个程序，根据需要建立被请求的文件。

测试示例代码的时候，你的本地系统或LAN可能太快了，以至于无法中断下载过程，因此我推荐你使用慢速LAN连接（在IIS中减少站点的带宽是一种模拟的方法）或者把服务器放到互联网上。

在客户端上下载文件仍然很艰难。ISP操作的不对的或配置错误的Web缓冲服务器都可能使大文件下载过程失败，包括下载状况恶化或早期对话终结。如果文件大小超过了255MB，你就应该鼓励顾客使用第三方下载管理软件，尽管某些最新的浏览器内建了基本的下载管理器。

如果你希望进一步扩展示例代码，查阅一下HTTP规范是有益的。你可以为下载建立MD5校验值，使用Content-MD5头信息添加它们，提供一种验证下载文件完整性的途径。示例代码除了GET和HEAD之外没有涉及到其它的HTTP方法。

本文链接