Platform: IIS 6, ASP.Net 2.0 (.Net 3.5), Server 2003.
I'm building an application that accepts files from a user, processes them, and returns a result. The file is uploaded using HTTP POST to an ASP.Net web form. The application is expecting some large files (hundreds of MB).
I'm using SWFUpload to accomplish the upload with a nice progress bar, but that's not contributing to the issue, because when I bypass it using a standard HTML form pointing at my upload accepter page, I get the exact same error. When using the progress bar, the upload continues to 100%, then fails. With a standard form, the behavior appears to be the same.
I'm having a problem right now uploading a file that's about 150MB. I've changed every settings I can find, but still no luck.
Here's a summary of what I've changed so far:
In Web.config:
Added this inside system.web:
<httpRuntime executionTimeout="3600" maxRequestLength="1536000"/>
In machine.config:
Inside system.web, changed:
<processModel autoConfig="true" />
to:
<processModel autoConfig="true" responseDeadlockInterval="00:30:00" responseRestartDeadlockInterval="00:30:00" />
and in MetaBase.xml:
Changed:
AspMaxRequestEntityAllowed="204800"
to:
AspMaxRequestEntityAllowed="200000000"
When the upload fails, I get a 404 error from IIS. My web form does not begin processing, or at least, it doesn't make it to the Page_Load event. I threw an exception at the beginning of that handler, and it doesn't execute at all on large files.
Everything works fine with smaller files (I've tested up to about 5.5MB). I'm not exactly sure what file size is the limit, but I know that my limit needs to be higher than 150MB, since this is not the largest file that the client will need to upload.
Can anyone help?
Urlscan was active on all websites, and has it's own request entity length limit. I wasn't aware that Urlscan was running on our server because it was a global ISAPI filter, not running on my individual website.
Note: to locate global ISAPI filters, right click on the Web Sites folder in IIS Admin and click Properties, then on the ISAPI Filters tab.
(A note for googlers):
For IIS7 add below to web.config (I added above <system.serviceModel>):
<system.webServer>
<security>
<requestFiltering><requestLimits maxAllowedContentLength="262144000" /></requestFiltering> <!-- maxAllowedContentLength is in bytes. Defaults to 30,000,000 -->
</security>
</system.webServer>
When we ran into this issue we had to increase the buffer size limit according to this KB article:
http://support.microsoft.com/kb/944886/en-us
I know this mentions ASP, but I believe it worked for ASP.NET as well.
Edit: Here is a link that might be more relevant to your issue and provide other options:
http://weblogs.asp.net/jgalloway/archive/2008/01/08/large-file-uploads-in-asp-net.aspx
404 and missing Page_Load: IIS can only process the request once the complete POST is on the server. Therefore, if the POST fails (due to its size), it cannot fire the page's events.
You might try NeatUpload http://www.brettle.com/neatupload.
From the Manual: "By default, NeatUpload does not directly limit the size of uploads."
You can also try Velodoc XP Edition which has several advantages over NeatUpload including the fact that it uses ASP.NET Ajax extensions. See also the Velodoc web site for more information.
You say:
But 1536000 is only 1.5MB?
Related
Got following Error:
HTTP Error 403.14 - Forbidden
The Web server is configured to not list the contents of this directory.
this is how I linked css file.
<link rel="stylesheet" type="text/css" href="~/styles/StyleSheet.css" />
i am using master page for first time. i did added master page in iss server.
i enabled the directory setting in my iss 8.0
Have you tried setting the following within your web.config file :
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
</system.webServer>
The Web server is configured to not list the contents of this directory
The keyword in the error is list.
That sounds more like you do not have a default document set up. If you don't have one, nor don't request a specific document (e.g. http://www.foobar.com/ or http://www.foobar.com/foo.html respectively) IIS will not "know" what to "serve" to the browser nor will it, nor should you expect it to, list the contents of that directory (instead).
See: Microsoft Support: Error 403.14
A Short Story Of A Lost Controller, And A Happy Ending
Let's say you have a controller called Data, in the project file /Controllers/DataController.cs. You can access it just fine via http://yoursite.com/data, which is handled by the DataController.Index action method.
Then, somehow, it breaks, and you start getting "The Web server is configured to not list the contents of this directory" when you visit this URL. Strangely, visiting /data/index still works! You try all the suggestions found online to make this work but can't seem to do it. What could it be?
Perhaps you ought to think about what the error means. It says that when you visit /data, it finds a directory there, but you aren't allowed to see the files in it. Setting aside the fact that your routing doesn't seem to work and it should, could there actually be a directory there?
Yes, there could! In your web project, you cleverly added folder /Data! This is a physical folder that takes precedence in the server's static routing rules (since you didn't rewrite those so physical files would be looked at after managed virtual paths).
The solution is thus to rename the folder, or rename the controller, one or the other. This will fix your problem quite speedily and you may then proceed on your merry way coding long into the night to the enveloping strains of techno Spanish mandolin trance music, with your trusty cat snoozing on your foot and the cold beverage of your choice beading up on the desk next to you!
The Ramesh Rajendran's answer must working, but you can use look at what is the modules your web application use and add in system.webServer tag on webconfig file to they use it. I had this error also in a test web application when I put it on Server IIS.
It's very strange not list the contents with the option enabled on IIS Web Server.
When you press Ctrl+F5, then IIS don't understand what to serve as you don't have any Default aspx file in your site , i recommend you to add a aspx file by going to Add>NewItem>Webform>
Note: remember to check the box at bottom right , "select from master page"
after selecting , save all the pages and just open your default.aspx file and you will surely see the reflected design as you did in master page.
Master pages are not aspx file but serve as a template for other webpages , so you cant just open master page.
Don't start the debugger while you are on the master page. EdSF pretty much summed up why.
In addition, you also may need to set a default start page(right click, set as start page).
You should define a default document value in web config and disable directory browsing.
<system.webServer>
<defaultDocument>
<files>
<add value="insertion.aspx" />
</files>
</defaultDocument>
<directoryBrowse enabled="false" />
We run a link redirection service which can handle links thrown at it in various formats. One of these formats is to append the destination URL to the end of the link, for example
http://url.fwd/abcd/http://www.mydomain.com/page.aspx
This was working on a Windows Server 2003 / IIS6 box for the last two years, but now we're trying to move to a Windows Server 2008 / IIS7 setup and its not working anymore.
I've read about the problem with colons in the URL but it doesn't affect pages not ending in '.aspx'. For instance,
http://url.fwd/abcd/http://www.mydomain.com/page.php
would redirect fine.
http://url.fwd/abcd/http//www.mydomain.com/page.aspx
also works fine (note the lack of a second colon). Despite being the wrong URL, it does get handled by our URL forwarding system, which uses a custom 404 page. On the old system, we had a similar problem, so a method was written in Global.asax > Application_Error specifically to handle the '.aspx' case, and it worked fine.
On our new server, the Application_Error never gets thrown in Global.asax. Instead, I get a System.NotSupportedException - "The given path's format is not supported". This System.NotSupportedException is the exact case we handle in the Global.asax page, so it's definitely not being fired.
I've changed the registry keys indicated in several forum posts,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET VerificationCompatibility=1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP|Parameters AllowRestrictedChars=1
I've tried changing the Handler Mappings settings for .aspx.
I've tried setting the App pool to use classic mode instead of integrated, but this causes a completely different error where static content such as images and CSS do not display at all. I've checked that static content is enabled in the windows features, and it is.
Under classic mode, the '.aspx' request throws two Bad Request errors with absolutely no information whatsoever. The code of the error page I get is literally
Bad Request<html><body>Bad Request</body></html>
UPDATE: I've changed the static file Handler Mapping to the form found in this page
http://improve.dk/blog/2006/12/11/making-url-rewriting-on-iis7-work-like-iis6
However, as the author rightly points out, this is a hack and not the correct way of doing things under IIS7. It also only fixes the static file problem in classic mode. '.aspx' pages still throw an error under classic mode.
Any thoughts or input would be greatly appreciated at this point.
IIS 7 Solution
The easy solution in IIS 7 is to add a setting in your web.config file to tell IIS to process all requests through your Global.asax events. Just add or change this section in your web.config to enable requests:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
In my case, I was publish my site in production and I miss copy to server App_global.asax.compiled file. For this reason was not fire the Events inside Global.asax.
Hope anyelse help this tips, I lost 8 hours seeking.
I set up iis to handle .exe with "asp.net 2.0"s isapi filter to enable dynamic url replacement.
For this I setup the extension in iis and added the following line to web.config. Works fine so far.
<add path="*.exe" verb="*" type="System.Web.StaticFileHandler" />
the problem is that form that point w3wp process has several handles on these files. Most likely because someone is downloading them at the moment.
Is there a way to tell iis/asp.net not to put a exclusive handle on the file? I want to replace them even if the site is running. This works as long as asp.net does not handle these files.
I don't think there is a way to do this. You are telling IIS to handle this filetype, so the server is assuming a certain exclusivity. This behavior is intended IMO, because it prevents corrupted files in production environment.
Maybe it helps to limit the requests to some selected HTTP verbs (POST/GET), but i don't see any other options.
And the other question is: why do you want to replace a file, that is currently downloaded by a user? It will corrupt his download, forcing him to start all over again.
Trying to upload a large file (20MB), I set the maxRequestLength to a high enough level (and the expiration time too) in the httpRuntime entry of web.config. The Event Log stopped reporting that the post size exceeds allowed limits, but I still get the same behavior in the browser (IE or FF): "The connection to the server was reset while the page was loading." I'm using VS2008 and the built-in web server, not IIS. I've read the Q&A on this topic and even put in the check for the exception (IsMaxRequestExceededEexception) in the application global handler. This was referenced in another StackOverflow thread about this topic. Anyone had anything similar, have any ideas?
Thanks,
Bob
Not come accross this myself with the built in server, however you could try increasing the time out too in the web.config file.
<httpRuntime executionTimeout="****" maxRequestLength="****" />
Figured out my problem. I put the entry into the wrong web.config file -- I have two web apps in the same VS solution. doh!
Http uploads are notoriously unreliable. You should look into some other options that utilize Flash or Silverlight for file uploads.
I have installed Static and dynamic compression for IIS7, as well as setting the two web.config values at my application Virtual Folder level. As I understand it, I don't need to enable compression at the server, or site level anymore, and I can manage it on a per folder basis using my web.config file.
I have two settings in my .config file that I have set to customize gzip for my app:
<httpCompression dynamicCompressionDisableCpuUsage="90"
dynamicCompressionEnableCpuUsage="0">
<scheme name="gzip" dll="%Windir%\system32\inetsrv\gzip.dll" />
<dynamicTypes>
<remove mimeType="*/*"/>
<add mimeType="*/*" enabled="true" />
</dynamicTypes>
</httpCompression>
<urlCompression doDynamicCompression="true"
dynamicCompressionBeforeCache="true" />
However, when I run the application, I can clearly see that gzip is not used, because my page sizes are the same. I am also using YSlow for FireFox, which also confirms that my pages are not being gziped.
What am I missing here? In IIS6 it was a simple matter of specifying the file types, and setting the compression level between 0-10. I don't see the need documented to specify the file types or compression level, since the defaults seem to cover the file types, and I'm not seeing the level anywhere.
There was a thread on forums.iis.net about this during the iis 7 beta. Turned out the guy didn't have the modules installed, but it sounds like you've ruled that out from your opening sentence.
Microsofts key advice for him was to enable failed request tracing to find out what was going wrong. This is possibly one of the most under-appreciated features of IIS7, but certainly one of the most powerful.
Open IIS Manager.
Go to your site, and on the actions pane (the very far right), click 'Failed Request Tracing...' under the 'Configure' section.
Click 'enable'.
Then, in the features view, click 'Failed request tracing rules'. Click add, next, enter 200 for the status code, next, click finish.
If you don't see "Failed Request Tracing" in the actions pane, you'll need to add the feature to the server - either using the "Add Role Services" wizard (Health and Diagnostics\Tracing) or through the Web Platform Installer (Products\Server\IIS: Tracing), and then close and re-open IIS Manager.
Next, rerun your test. This will generate some log info for us to examine.
Look in c:\inetpub\logs\FailedReqLogFiles\w3svcx. You will see a bunch of files named fr000xx.xml. Open up any one of them in your browser. (By the way, if you copy these files anywhere, make sure freb.xsl is there. Also, don't delete freb.xsl - if you do, just delete the whole directory or copy it from another location, as IIS only creates it once per folder.)
Click the 'request details' tab and select 'complete request trace'. Search the page for 'compress' - you should find it in several areas; once for static content, and once for dynamic content.
If you don't find either of them, IIS isn't configured correctly. If you do find them, you should see them followed by a compression_success and a compression_do. Success is self explanatory; the 'do' indicates what it did - in my case, it showed "OriginalSize 1462784 CompressedSize 179482"
Since yours isn't working, hopefully you will see something different that helps you solve the problem.
Make sure you turn this off when you're done by disabling failed request tracing in the actions pane for your website.
We had a similar problem and it turns out that IIS7 does some dynamic CPU based throttling here..
http://www.iis.net/ConfigReference/system.webServer/httpCompression
dynamicCompressionDisableCpuUsage
Optional uint attribute.
Specifies the percentage of CPU utilization at which dynamic compression will be disabled.
Note: This attribute acts as an upper CPU limit at which dynamic compression is turned off. When CPU utilization falls below the value specified in the dynamicCompressionEnableCpuUsage attribute, dynamic compression will be reenabled.
The default value is 90.
dynamicCompressionEnableCpuUsage
Optional uint attribute.
Specifies the percentage of CPU utilization below which dynamic compression will be enabled. The value must be between 0 and 100. Average CPU utilization is calculated every 30 seconds.
Note: This attribute acts as a lower CPU limit below which dynamic compression is turned on. When CPU utilization rises above the value specified in the dynamicCompressionDisableCpuUsage attribute, dynamic compression will be disabled.
The default value is 50.
Note the defaults -- if your IIS7 hits 90% CPU usage, it will disable all dynamic gzipped content until CPU usage dips back below 50%!
Also, some great recommendations and benchmarks here on the real CPU cost of GZIP.
http://weblogs.asp.net/owscott/archive/2009/02/22/iis-7-compression-good-bad-how-much.aspx
Long story short, unless you regularly have dynamic pages well in excess of 200kb, it's a non-issue.
Following the excellent advice of JohnW, I too enabled logging to find the culprit, though the reason for the failure turned out to be different:
STATIC_COMPRESSION_NOT_SUCCESS
Reason 14
Reason NOT_FREQUENTLY_HIT
In short, it appears that if you don't hit the page frequently enough then IIS7 will not deem it worthy of compressing, which seems a little bit odd to me. Nonetheless, makes sense in this case because I was just trying to test it on a local machine.
According to this page, the default appears to be that a page has to be hit 2 times within 10 seconds to be a "frequent hit". If you really want to, you can override the default in applicationHost.config (%systemroot%\Windows\System32\inetsrv\config). At least for me it's a locked attribute, so you won't be able to override it in your own web.config.
<serverRuntime frequentHitThreshold="1" />
Also, I note now that SO already had this answer here: In IIS7, gzipped files do not stay that way.
I solved my problem by installing dynamic compression at Add/Remove programs.
In the system.webServer section of your Web.config file, add the following lines:
<remove fileExtension=".js" />
<mimeMap fileExtension=".js" mimeType="application/x-javascript" />
The compression scheme in IIS7 is enabled by default, but it maps only a single javascript mime type to be compressed, application/x-javascript. Adding the line above tells IIS to give all your .js files that mime type, which in turn makes the compression work.
turn on static compression. dynamic compression is for dynamic pages like asp, php, aspx, etc.
Here's a link to the IIS config reference for compression:
For me it turned out to be the setting
noCompressionForProxies
as we are on a proxy here...took myself off proxy and voila, compression.