UploadReadAheadSize Article

So, what is the problem with the UploadReadAheadSize? Let's take a look at htpp client (IE, for example) and IIS server (+ASP for our case) communication with UploadReadAheadSize set to default (48kB) and to zero.
1. UploadReadAheadSize set to default (48kB)

1. IE sends http headers with bad Content-Length, for example
POST /upload/huge-asp-upload.asp HTTP/1.1
Content-Length: 54834126
...

2. IIS Server sends immediate response:
HTTP/1.1 100 Continue
Server: Microsoft-IIS/5.0
...

3. Client sends source data, kilobytes, megabytes:
-----------------------------7d4180c1901f0
Content-Disposition: form-data; name="File1"; ...

4. Server reads first 48kB of a source data first (UploadReadAheadSize) and the control is passed to application handling the POST - ASP in our case. So ASP can begin read http headers and data after all prevous actions.

5. ASP (and COM objects in ASP page or script) can read the headers and data and process them. This is the reason that clients on modems (or similar slow connection) cannot see progress of the upload for first 12-15second. It is the time to upload the 48kB of data.

    So we can continue: what happens when server accepts and refuses request? If the request is accepted, there is no problem. IE sends the data, IIS server reads the data and pass them to ASP. The ASP is processing the data and the data are stored to the disk. No problem.
    Another situation is if you want to refuse request. Client browser has already received '100 Continue', so if you try to write something like
If Request.TotalBytes>0 Then
  Response.Status = "413 Request Entity Too Large"
  Response.End

...
in your ASP page, client browser is confused. so

6. Server tries to send response '413 Request Entity Too Large' response to client

7. Client knows nothing about the response and the client (IE in our case) is hustling  the source data to the server, regardless of results. But server closes the connection and tries to treat the source data as a firtst http block - http header. The response from server is '400 bad request'

8. Client knows nothing about the server response once again and the data flow to the server continues. IE usually sends 100-1000kB. Then  IE awakes suddenly ans stops to send the source data flow. But! Strange! IE tries to send the source data once again from the begginning, step 1. header, etc. But the new source data are corrupted! IE sends complette header now, but the source form data are truncated to the 100-1000kB length and http header contains the new corrupted length! (So, if you try to handle this situation by ASPForm, you will receive fsInProgress as a State.)

2. UploadReadAheadSize set to zero (0kB)

So what happens in such case? The server response is right now:

1. IE sends http headers with bad Content-Length, for example
POST /upload/huge-asp-upload.asp HTTP/1.1
Content-Length: 54834126
...

2. UploadReadAheadSize is zero, so IIS does not send HTTP/1.1 100 Continue. It directly pass control of the request to processing script. ASP (and COM objects in ASP page or script) can read the headers and data and process them, before IIS sends any response to the client. You can try to refuse the request now as in previous case. 'HTTP/1.1 413 Request Entity Too Large' is sent to a client instead of 'HTTP/1.1 100 Continue'.

3. But unexpectedly, client browser does not expect anything else than 'HTTP/1.1 100 Continue'. Ignores the response from server and sends the data stream to the server as in previous case. And IE repeats the steps 1.-3. several times.

   The latest versions of IE (6.0.28 ...) has another behavior. They try to send the data only once again, corrupted and page 'cannot be displayed' is shown. It is similar to Mozilla and it's 'The document contains no data' message.

And results with UploadReadAheadSize? There is better to set the property to zero when uploading files. The server response is correct in such case. But the client cannot see the response, because browsers does not have defined standard behavior for the situation ...

I tried several other responses, including 303 See other, 400 bad request, 302 moved, nothing...

ScriptUtils.ASPForm.Upload - Files and forms with large/huge size..IIS Limit Check

IIS Limit Check is a simple application, which let's you check main IIS parameters important for upload files.

ScriptUtils.ASPForm.Upload - Files and forms with large/huge size.

Brief overview of work with very large files. ASPForm configuration and IIS setting for huge uploads or urlencoded forms with big fields.

ScriptUtils

Huge ASP upload is easy to use, hi-performance ASP file upload component with progress bar indicator. This component lets you upload multiple files with size up to 4GB to a disk or a database along with another form fields. Huge ASP file upload is a most featured upload component on a market with competitive price and a great performance . The software has also a free version of asp upload with progress, called Pure asp upload , written in plain VBS, without components (so you do not need to install anything on server). This installation package contains also ScriptUtilities library. Script Utilities lets you create hi-performance log files , works with binary data , you can download multiple files with zip/arj compression, work with INI files and much more with the ASP utility.