Adjusting IIS settings to simplify Windows Server client uploads

Many websites let users upload content directly through a web browser, but this way lacks the interactivity between the user and the remote server, thus allowing them Interaction has not been so easy. First of all, there is basically no feedback during the upload process, and sometimes the only feedback that is obtained after a long wait is an annoying error. Still, using a browser to upload files is still a widely accepted method of file transfer. Because users prefer its simplicity, rather than the laborious use of File Transfer Protocol (FTP) tools. Although this method is widely accepted, it does not guarantee that it will not go wrong. A confirmed Microsoft IIS problem is that a timeout error occurs when processing an upload file larger than 48K. Sometimes this is just an upload failure, but at other times this will cause the browser to enter an infinite loop of constantly trying to resend data. Because for the browser, there is no standard response for this particular situation. The reason for this hang is that IIS uses an application such as ASP to handle the upload of client data. When the client starts committing data, IIS reads the first 48K of data into the buffer and passes it to the application for processing. Any data that exceeds this 48K will be in a wait state until the application requests a transfer, usually through a command like Request.BinaryRead(Request.TotalBytes). If the application does not request, the data is waiting for a connection. This is a typical 413 error: the request entity is too large. In general, good coding in accordance with the above rules can avoid such problems, but in some cases you may need to use specific property settings. For example, if the upload of one of your sites is handled by a third-party ISAPI extension, it does not follow this practice, and some adjustments are needed to overcome the 48K limit. This restriction is not static, it is defined by a IIS metadata attribute called UploadReadAheadSize. The default is 49152K and the maximum can be set to 4GB. If you need to, you can set up a separate site or set up the entire IIS service. This may not be the only property that needs to be set. You may also need to modify the maxRequestLength (in IIS6) or maxAllowedContentLength (in IIS7+) attribute values ​​to allow large data uploads, although their default values ​​are larger. In some cases, it can be helpful to set the value of UploadReadAheadSize to zero. This forces IIS to stream the submitted content directly to the ISAPI extension application to process the request. This may be the first method worth trying to solve this problem, but you should also notice the possible side effects of shutting down the IIS application (without processing the read-ahead buffer). Finally, keep in mind that increasing the value of UploadReadAheadSize will produce an attack surface. If this value is set high and someone wants to attack your system by uploading files to consume bandwidth, they will be easy to get. To avoid attacks, use a method that reflects the user's actual usage and insist on using authentication as much as possible to ensure that the uploader's identity is trustworthy.