调整IIS设置简化Windows Server的客户端上传[操作系统]

很多网站都是通过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的值会产生一个攻击面.假如这个值设置得很高,并且有人想操纵通过上传文件来耗费带宽的方法攻击你的系统,他们将很简单到手.为了避免攻击,利用一个可以表现用户实际利用的值,并尽大概地保持利用身份考证的方法,以确保上传者的身份值得信任.