Request Entity too large 413 error Request Entity is too large

C: \ Inetpub \ adminscripts

Cscript adsutil. vbs set w3svc/3/uploadreadaheadsize 8388608

 

3 is the website ID

 

C: \ windows \ system32 \ inetsrv \ config

The website ID can be found in applicationhost. config.

Refer:

Http://blogs.msdn.com/ B /jiruss/archive/2007/04/13/http-413-request-entity-too-large-can-t-upload-large-files-using-iis6.aspx

 

Http://forums.iis.net/t/1169257.aspx

 

Http://news.bangkaow.com/news/20110601/179540.html

Many websites use Web browsers to allow users to directly upload content. However, this method lacks the interaction between users and remote servers, making interaction easier. First, there is basically no feedback during the upload process. Sometimes the only feedback you get after a long wait is an annoying error.

Even so, using a browser to upload files has become a widely accepted file transmission method. Because users prefer its simplicity, rather than using the file transfer protocol (FTP) tool.

Although this method is widely accepted, it cannot guarantee that no error is made. One confirmed Microsoft IIS problem is that a timeout error occurs when processing files larger than 48 KB. Sometimes this is only an upload failure, but other times it will make the browser into an endless loop of attempts to resend data. For browsers, there is no standard response for this particular situation.

The reason for this suspension is that IIS uses an application such as ASP to process client data uploads. When the client starts to submit data, IIS reads the first 48 k of data into the buffer zone and passes it to the application for processing. Any data that exceeds the value of 48 KB will be in the waiting state until the application requests are transmitted. It is generally executed using a command similar to request. binaryread (request. totalbytes. If the application has no request, the data is in the waiting for connection status. This is a typical 413 error: the request entity is too large.

Generally, such problems can be avoided by well-coding according to the above rules, but in some cases, you may need to use specific attribute settings. For example, if a website is uploaded by a third-party ISAPI extension and does not follow this method, you need to make some adjustments to overcome the 48 k limit. This restriction is not static. It is defined by an IIS metadata (metabase) attribute named uploadreadaheadsize. The default value is 49152 K, and the maximum value can be 4 GB. If necessary, you can set a separate site or set the entire IIS service.

This may not be the only property to be set. You may also need to modify the attribute values of maxrequestlength (in IIS6) or maxallowedcontentlength (in iis7 +) to allow uploading of large data, even though their default values are large.

In some cases, setting the value of uploadreadaheadsize to zero is helpful. This forces IIS to directly flow the submitted content 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 note the side effects of disabling the IIS application (not processing the pre-read buffer.

Finally, remember that adding the value of uploadreadaheadsize will generate an attack surface. If this value is set very high and someone wants to attack your system by uploading files to consume the bandwidth, they will be very easy. To avoid attacks, use a value that can reflect the actual use of the user, and try to stick to the authentication method as much as possible to ensure that the identity of the uploaded person is trustworthy.