Question about HTTP file POST

On Nov 26, 1:31 am, Chris Ashley <chris.ashl....DeleteThis@gmail.com> wrote:
> Hi,
>
> I have a question about using the <input type='file'> type with a
> multipart/form-data HTTP POSTed form on IIS.
>
> Does IIS always stream the POSTed file data to memory, or does it
> stream to disk if memory is short? I am worried about our server
> falling over if lots of people suddenly upload files with a total of
> more than the servers available memory..



The answer depends on the URL you use to handle the POST.

IIS itself does not stream or do anything with the POST data. It just
gives server-side application access to that data.

The application executed by the URL controls how to stream the POST
data, so it can choose to stream it to disk, or buffer to memory. For
example, application frameworks like ASP and ASP.Net buffer a what is
read via Request.BinaryRead() to memory, but the application can
choose to write that data to disk or to continue buffering in memory.

Thus, IIS does not control streaming behavior at all. In fact, it is
not possible for IIS to gracefully limit POST data size (i.e. you
can't prevent people from uploading 4GB files gracefully) because the
HTTP spec around this behavior is confusing from a backward-
compatibility point of view (i.e. 100-continue is supposed to allow
this for HTTP/1.1 clients and servers, due to existence of HTTP/1.0
servers and clients, even HTTP/1.1 clients tend to violate and ignore
100-continue logic).

As Anthony mentions, there are a variety of tricks that one can do on
a 32bit Windows OS to work with applications that buffer to memory to
provide it the memory it wants, but those are work-arounds.

The only way to get nice control of upload/download sizes is to invent
and use your own protocol with XML Http, like GMail or Hotmail.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
 >> Stay informed about: Question about HTTP file POST