|
|
许多网站都是通过Web浏览器让用户直接上传内容，但是这种方式缺乏用户与远端服务器之间的交互性，从而让他们的互动变得不那么容易。首先，在上传过程中基本没有什么反馈，有时在经历了漫长的等候 后得到的独一 反馈却是一个厌恶 的报错。
虽然 如此，使用浏览器来上传文件还是成为被普遍 承受 的文件传输方式。由于 用户更喜欢它的烦琐 ，而不是费力 的去使用文件传输协议 （FTP）的工具。
虽然这种方式被普遍 承受 ，但它并不能保证不出错。一个确认的微软IIS问题就是在处理大于48K的上传文件时会出现一个超时报错。有时这只是一次上传的失败，但其它时候这会让浏览器进入一个不停尝试重新发送数据的死循环。由于 对于浏览器来说，没有一种针对这种特定状况 的标准响应。
这种挂起的原因是IIS使用一种如ASP的应用程序来处理客户端数据的上传。当客户端开始提交数据时，IIS将第一个48K的数据读入缓冲区，然后将其传送 给应用程序进行处理。任何超出这48K的数据会处于等候 状态直到应用程序恳求 传输，通常通过类似Request.BinaryRead（Request.TotalBytes）的命令来执行。假如 应用程序没有恳求 ，这些数据则处于等候 连接状态。这是一个典型的413报错：恳求 实体过大。
通常，依照 上述规则进行良好的编码可以避免此类问题，但某些状况 下可能需要. 使用特定的属性设置。例如，假如 你的某个站点的上传是由第三方的ISAPI扩展来处理的，它没有遵照 这种做法，此时就需要. 进行一些调整来克制 48K的限制。这个限制不是原封不动 的，它通过一个名为UploadReadAheadSize的IIS元数据（metabase）属性来定义。默认值为49152K，最高可以设为4GB。假如 需要. 的话，你可以对一个单独的站点进行设置也可以设定整个IIS服务。
这可能不是独一 需要. 设置的属性。你可能还需要. 修改maxRequestLength（在IIS6）或maxAllowedContentLength（在IIS7 +）的属性值来允许大型数据的上传，虽然 它们的默认值也较大。
在某些状况 下，将UploadReadAheadSize的值设为零会很有帮助。这会强迫 IIS将提交的内容直接流向ISAPI扩展应用来处理该恳求 。这可能是在解决这个问题时首先值得尝试的方法，但是你也应该注意到关闭IIS应用程序（不处理预读缓冲区）可能带来的反作用 。
最后，请记住，增加UploadReadAheadSize的值会产生一个攻击面。假如 这个值设置得很高，并且有人想应用 通过上传文件来消耗 带宽的方式攻击你的系统，他们将很容易得手。为了避免攻击，使用一个可以 表现 用户实际使用的值，并尽可能地坚持使用身份验证的方式，以确保上传者的身份值得信任 。
|
|
|
|
|
|
|
|
|
|
