Is there any future plan to support HTTP Server side File Upload? about mormot2 HOT 6 OPEN

It is indeed not yet supported.

But it is planned in the close future, with the upcoming proxy and reverse proxy features of our async server.
We need this, because nginx is no option on Windows, and our async server using IOCP seems to be pretty fast, so we will continue to enhance it.

So stay tuned, we will support it, I hope before the end of this year.
I guess you can close this issue, and open it back in a few weeks if you see no progress in that direction.

from mormot2.

Note that all the internal logic for using a TStream instead of a RawByteString is already there.
We just need a mean to trigger it properly.

Perhaps in OnBeforeBody or - perhaps better - with a route registration.
What do you think?

from mormot2.

I was writing notes about building something using OnBeforeBody and Parsing the Headers.
And then we know we have the Content-Type to detect the multipart file upload and the Content-Length.
And for sure, the boundary string means that we know this is the end of file data and that we have started a new file.

var 
  Files : THttpMultiPartStream;  
Begin
  Files := THttpMultiPartStream.Create;
  Files.AddFile('files', 'F:\UploadTest\hello.txt'); // Contains 'Hello'
  Files.AddFile('files', 'F:\UploadTest\world.txt'); // Contains 'World'
  Files.Flush; 
  ...
End;

Headers for it on the server side look like this

Cache-Control: no-cache
Connection: Close
Pragma: no-cache
Content-Type: multipart/form-data; boundary=oKhwAf29zfOYjwQy
Accept: */*
User-Agent: Mozilla/5.0 (Win x64; mORMot) WH/2 FileUpload_Debug64
Content-Length: 368
Host: localhost

The content will be

--oKhwAf29zfOYjwQy
Content-Disposition: form-data; name="files"; filename="hello.txt"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: binary

Hello
--oKhwAf29zfOYjwQy
Content-Disposition: form-data; name="files"; filename="world.txt"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: binary

World
--oKhwAf29zfOYjwQy--

Considering that the content will be sent in chunks, a little bit of parsing would be required to detect when a file ends.

Adding a route registration for file upload is also a great idea.

from mormot2.

My guess is that our TStream support should be separated from mullti-part decoding, because

• Huge content could be sent without multi-part, but e.g. with or without chunking
• A single TStream is not a good candidate to split several multi-part files content

Most advanced reverse proxy servers do use a temporary file as output.
Letting a callback generate a TStream from the received input may be a good similar solution.

from mormot2.

My guess is that our TStream support should be separated from mullti-part decoding, because

• Huge content could be sent without multi-part, but e.g. with or without chunking

What about saving the entire data into a temp file, and then we do the parsing? I know parsing in memory is way faster, but we can handle all cases this way.

• A single TStream is not a good candidate to split several multi-part files content

That's true, but when a multi-file begins to be sent, it will be sent in one request; that's why I thought about the temp file and then parsing things. Of course only if needed data was found to be parsed.

Most advanced reverse proxy servers do use a temporary file as output. Letting a callback generate a TStream from the received input may be a good similar solution.

In this case, route registration for file upload is necessary so that any file upload requests will be ignored and the connection terminated. This can prevent a lot of DDOS attacks. But still, the user is the one responsible for handling all the cases.

from mormot2.

Yes, the TStream would be a file, either with a name supplied by the callback, or a temporary name.

from mormot2.