.NET big file upload knowledge finishing (reproduced)

File to process:

The change you need to do in the HTML DTD is an option for the InputType entity. In addition, we also recommend using a series of comma-separated file types as an INPUT tag an Accept property.

... (other elements) ...

Radio | Submit | RESET |

Image | hidden | file)>

TYPE% InputType Text

Name CData #implied - Required for All But Submit and Reset

Value cdata #implied

SRC% URI # IMPLIED - for Image Inputs -

Checked (Checked) # Implied

Size cdata #implied --Like Numbers, But Delimited with Comma, Not Space

Maxlength Number #implied

Align (Top | Middle | Bottom) #implie

Accept cdata #implied --List of content type

>

... (other elements) ...

2. Document transmission delay

In some cases, the server is a recommended approach to certain elements (such as user name, account, etc.) in form data before being prepared to accept data. However, after a certain consideration, we think that if the server wants to do this, it is best to use a series of forms and transfer the data elements you have verified as the "hidden" field to the client, or by schedule The form makes those elements that need to be verified first. In this case, those servers that need to be complex applications can maintain their own state, and those simple applications can be made simple.

The HTTP protocol may need to know the total length of content in the entire transaction. Even if there is no clear requirement, the HTTP client should also provide the total length of all files, such a busy server can determine if the contents of the file are too large to process, thereby returning an error code and shutting down This connection does not have to wait until all data is accepted. At present, some existing CGI applications need to know the total length of content for all POST transactions.

If the INPUT tag contains a MaxLength property, the client can regard this property value as the maximum number of bytes that the server can accept. In this case, the server can prompt the client on the server before the start of the server can be used to upload. But it should be noted that this is just a prompt, and the actual needs of the server may change before the form is created and uploaded.

In any case, if the received file is too large, any HTTP server may interrupt the transfer during file transfer.

3. Other solutions to transfer binary data

Some people have suggested using a new MIME type "aggregate", such as aggregate / mixed or content-transfer-encoding "package" to describe the binary data that is not determined, not by decomposition into multiple parts. . Although we don't object to do, this requires additional design and standardization work to let everyone accept and understand "aggregate". From another aspect, the mechanism of "decomposition is multi-part" work is well, which is very simple to implement in the customer sender and server acceptance, and can be as highly efficient as other integrated binary data. jobs.

4. Example

Suppose the server segment is provided with the following HTML:

ENCTYPE = "Multipart / Form-Data"

Method = POST>

What is your name?

What Files Are you sending?

Users fill in "Joe Blow" in the Name field, to the problem 'What files are you sending?', Users choose

A text file "file1.txt".

Customer segment may send back the following data: Content-Type: Multipart / Form-Data, Boundary = AAB03X

--Aab03x

Content-disposition: form-data; name = "field1"

Joe Blow

--Aab03x

Content-disposition: form-data; Name = "pics"; filename = "file1.txt"

Content-Type: Text / Plain

... File1.txt content ...

--Aab03x -

If the user also selected another picture file "file2.gif", the data that the client may send will be:

Content-Type: Multipart / Form-Data, Boundary = AAB03X

--Aab03x

Content-disposition: form-data; name = "field1"

Joe Blow

--Aab03x

Content-disposition: form-data; name = "PICS"

Content-type: Multipart / Mixed, Boundary = BBC04Y

--Bbc04y

Content-disposition: attachment; filename = "file1.txt"

Content-Type: Text / Plain

... File1.txt content ...

--Bbc04y

Content-disposition: attachment; filename = "file2.gif"

Content-Type: Image / GIF

Content-Transfer-Encoding: binary

... File2.gif's content ...

--Bbc04y--

--Aab03x -

Second, using the RFC1867 standard processing file upload:

1. The uploaded data is obtained in one time, then analyze the processing.

After seeing N multi-code, there is discovered that there is currently no component program and some COM components are used using the Request.BinaryRead method. The uploaded data is obtained in one time, then analyze the processing. That's why the big file is very slow, IIS timeout does not say, even if there are hundredsm files, the analysis process has to be a while.

2. While receiving the file, write a hard drive.

Learn about foreign business components, more popular with Power-Web, Aspupload, ActiveFile, Abcupload, Aspsmartupload, Sa-fileup. Among them, the relatively excellent is aspupload and sa-file, they have known 2G files (SA-File E version of the SA-File E version does not even limit the limit of the file size), and the efficiency is also very good, is there so many efficiency of the programming language? Information, I think they are directly operating the file stream. This is not restricted by the size of the file. But the foreigners are not absolutely perfect, and after the AspupLoad handles large files, the memory occupation is amazing. 1G is very generous. As for SA-File, although it is good, it is hard to find. Then found 2 .NET upload components, lion.web.uploadModule and ASPNETUPLOAD are also operating file streams. But upload speed and CPU usage are not as good as foreigated business components.

Made a test, the LAN passed the 1G file. The ASPUPLOAD upload speed is 4.4m / s, the CPU takes up 10-15, and the memory occupies 700m. SA-File is also almost like this. ASPNETUPLOAD is only 1.5m / s, and the average is 700k / s, the CPU takes up 15-39, the test environment: PIII800, 256M memory, 100M LAN. I think the ASPNETUPLOAD is slow to write the hard drive because of the reception file. The cost of resource occupation is to reduce the transmission speed. But I have to admire foreigners, the CPU takes so low ..... III, the problem encountered by the ASP.NET uploaded

We have encountered such or such problems when using major files on ASP.NET. Setting big maxRequestLength values ​​do not completely solve the problem, because the ASP.NET will block until the entire file is loaded into memory. In fact, if the files are large, we often see Internet Explorer display "The page cannot be displayed - cannot Find Server or DNS ERROR", it seems to be Catch can't. why? Because this is a Client Side error, the Application_ERROR of the Server Side end is derived.

Fourth, ASP.NET big file upload solution

The solution is to use an implicit HttpWorkerRequest to read the data from the PIPE established by IIS as ASP.NET with its GetPreLoadedEntityBodyRequest. Chris Hynes provides us with such a solution (with httpmodule), which can display upload progress in real time in addition to allowing you to upload large files.

Lion.Web.uploadModule and ASPNETUPLOAD two .NET components are using this solution.

Principle:

Using the HTTPHandler implements the functionality of the ISAPI Extens, the request (REQEST), and the response.

Program points:

1. Httphandler or httpmodulea. Intercept request object B. Brake read and write data c. Real-time tracking upload schedule update meta information

2. HttpWorkerRequest use implied by its GetPreloadedEntityBody ReadEntityBody and method for processing stream file IServiceProvider provider = (IServiceProvider) HttpContext.Current; HttpWorkerRequest wr = (HttpWorkerRequest) provider.GetService (typeof (HttpWorkerRequest)); byte [] bs = wr.GetPreloadedEntityBody ( ); .... if (! Wr.isentirentityBodyispreLoaded ()) {INT N = 1024; Byte [] bs2 = new byte [n]; while (wr.readentityBody (BS2, n)> 0) {.... }

3. Custom Multipart MIME parser automatically intercepting MIME splitting files to write files such as temporary files

Real-time Update Appliaction Status (ReceivingData, Error, Complete)