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/upload-base.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/upload-base.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...