G
Guest
I've already posted this question on the IIS forum, but it seems the problem
is not IIS related. I have an ASP.NET application that does big uploads on
the server (around 50Mo-100Mo). It works perfectly well on all versions of
the .NET framework on IIS 5.x, but on IIS 6.0 when the file is big, the
upload fails randomly (as if the server had given up on the request).
At first, I thought it was related to the size of the file, though I had put
a very high limit for httpMaxRequest, but it was not the case, since
sometimes files around 60Mo would pass, and sometimes 10Mo wouldn't.
It's not memory related either, the w3wp.exe process doesn't grow that much.
The error would never come at a the same time, even for the same file (for a
10Mo file, it would pop at 3'45'' or 3'14'', randomly).
Then, I thought about timeouts : and there it was, when putting a very high
timeout in the web.config file, all uploads pass. But the timeout stops the
request before it hit any code in the aspx page (I put a debug instruction at
the very first line to make sure of that), so it'sno need putting the timeout
value in the page. My guess is that the ASPNET ISAPI filter in IIS 6.0 kernel
mode starts the timeout when the request is first initiated on the server,
though at this time the request is not complete (the server only has headers
and stuff that permits it to determine that ASPNET has to be called, but it
doesn't have the whole multipart content). Then, it waits for the rest of the
request to arrive from the network. When the request is here, the filter
examines the request once again, realizes the time is up, and stops
everything. In IIS 5.x, the request would be first entirely read in IIS, then
given to the aspnet.exe worker process that would start its timeout only at
this time.
Can anybody from Microsoft tell me if I am right ? If so, can I consider
this is a bug, or at least something that people should be aware of ? If this
is the case, can I work around the problem by providing a HttpModule that
would set the timeout appropriately only for those types of request, because
it's always good to have low timeouts for normal requests ?
Thanks for reading this long post.
Regards
François Lemaire
is not IIS related. I have an ASP.NET application that does big uploads on
the server (around 50Mo-100Mo). It works perfectly well on all versions of
the .NET framework on IIS 5.x, but on IIS 6.0 when the file is big, the
upload fails randomly (as if the server had given up on the request).
At first, I thought it was related to the size of the file, though I had put
a very high limit for httpMaxRequest, but it was not the case, since
sometimes files around 60Mo would pass, and sometimes 10Mo wouldn't.
It's not memory related either, the w3wp.exe process doesn't grow that much.
The error would never come at a the same time, even for the same file (for a
10Mo file, it would pop at 3'45'' or 3'14'', randomly).
Then, I thought about timeouts : and there it was, when putting a very high
timeout in the web.config file, all uploads pass. But the timeout stops the
request before it hit any code in the aspx page (I put a debug instruction at
the very first line to make sure of that), so it'sno need putting the timeout
value in the page. My guess is that the ASPNET ISAPI filter in IIS 6.0 kernel
mode starts the timeout when the request is first initiated on the server,
though at this time the request is not complete (the server only has headers
and stuff that permits it to determine that ASPNET has to be called, but it
doesn't have the whole multipart content). Then, it waits for the rest of the
request to arrive from the network. When the request is here, the filter
examines the request once again, realizes the time is up, and stops
everything. In IIS 5.x, the request would be first entirely read in IIS, then
given to the aspnet.exe worker process that would start its timeout only at
this time.
Can anybody from Microsoft tell me if I am right ? If so, can I consider
this is a bug, or at least something that people should be aware of ? If this
is the case, can I work around the problem by providing a HttpModule that
would set the timeout appropriately only for those types of request, because
it's always good to have low timeouts for normal requests ?
Thanks for reading this long post.
Regards
François Lemaire