Large file upload/download using IIS

[Paul Baker [MVP, Windows - SDK]]

I have a Windows client application that needs to be able to transparently
upload and download large files to and from our server.

What are the limitations on file sizes when using IIS HTTP and can they be
worked around? I think the problem may only be with requests, not responses.
For requests, I believe I read the limit is configurable up to 1GB on IIS6
and 2GB on IIS7, but what is the underlying cause of this limit? Does it
read the entire request into memory before proceeding and, if so, is it IIS
that is doing it or the ISAPI handler (like ASP) that is doing that? It
seems like you should be able to read the request as it becomes available
and dump it to a file with minimal resource usage.

Some background information:

Currently, we use the FTP protocol with a Serv-U server. We always use the
PASV command (passive FTP), but despitre that we have a significant and
ever-growing number of repeat customers who experience routine connectivity
problems, most of which can probably be explained by firewalls or other
security intervention.

We have not been able to successfully troubleshoot the cause and resolve it,
probably by adding a firewall exception, in any of these cases except a
couple where the customer finally realised it on their own. This is due to a
lack of expert support technicians who are capable of dealing with it.

I am considering, as one possible solution, using the HTTP or HTTPS
protocol, which should be more firewall friendly. However, these files are
large. They are often hundreds of MB and I would like to be able to support
multiple GB, as the revenue for processing the file is approximately
proportional to the size of the file and I don't want to do something that
would exclude those large customers.

Thanks,

Paul

[WenYuan Wang [MSFT]]

Hello Paul,

We need to perform more research on this issue . We will reply here as soon
as possible.
If you have any more concerns on it, please feel free to post here.

Thanks for your understanding!
Best regards,

Wen Yuan
Microsoft Online Community Support
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Lognoul, Marc (Private)]

The limits depend on the server-side engine such as asp or asp.net or
something else (ISAPI), as well as the way requests are handled.

To overcome possible limitations, i'd advise to evaluate FileUp from
Softartisans (http://fileup.softartisans.com/fileup-246.aspx).
Note: I am just referring them but I am not involved in their business at
all and make no guarantee.

Marc

"Paul Baker [MVP, Windows - SDK]" <paulrich...@community.nospam> wrote
in message news:e7$qrGabI...@TK2MSFTNGP04.phx.gbl...

[WenYuan Wang [MSFT]]

Thanks for Lognoul's reply.

Hello Paul,
Thanks for your patience,

IIS does not have a builtin way to upload files - the limit may depend on
what you use for uploading asp/asp.net/webdav/fpse probably have their own
limits - some which can be configured, some cannot.

In ASP, there is no builtin upload function. There are free/commercial
products doing that for you on the server side. It's mostly not an issue
until you go over 2G. Wininet's content-length is a signed 32 bit type
between -2G and 2G. You can hack WinHttp to have a bigger content-length.
Or your client side can try chunked encoding.

On the server side, ASP.NET seems caching the content into the memory. If
you want larger once, you probably should create a custom HttpModule to
parse and save the data to a temporary storage.

By the way, you might also have a look of Bits service as well. I haven't
tried myself. It's supposed to handle both upload and download with resume
functions.

Hope this helps.

[Paul Baker [MVP, Windows - SDK]]

Thanks WenYuan and Longnoul.

I am going to continue to try to make FTP work for a while. There's nothing
wrong with the protocol when using the PASV command, and at least in the old
days it was the definitive protocol for transferring files.

But now I know what my options are and understand enough about the
limitations to proceed. BTW, I already figured I might have a problem on the
client, server or both with a Content-Length over 2GB. I will have to think
about that.

I would have to think hard about BITS. We have a fair number of customers
with clients that would not support it, and I don't want to install a large
component simply to transfer a file when FTP should be fine.

Paul

"WenYuan Wang [MSFT]" <v-wy...@online.microsoft.com> wrote in message
news:wa9GDzsb...@TK2MSFTNGHUB02.phx.gbl...