Is it possible to increase the request timeout for just the one particular web page? I am working on ASP.Net 4.0 and I need one particular page to have a longer request timeout, since it is responsible for initiating a long running process. Thanks.
Use Web.config:
<location path="Page.aspx">
<system.web>
<httpRuntime executionTimeout="180"/>
</system.web>
</location>
This is an old thread, but it should be emphasized that updating the executionTimeout of a page or the entire machine must also be accompanied by the compilation debug flag being set to "false", otherwise the timeout element is ignored.
Also, depending on whether or not you are using AJAX update panels, you may also have to look at the AsycPostBackTimeout flag on the ScriptManager itself - depends on how your timeout is manifesting itself. Ajax post back timeouts will be seen as error messages logged to the Javascript Console and tend to manifest themselves as ajax operations "dying on the vine" depending on how you are handling things.
The debug="false" bit is probably what is afflicting the gentleman above who was having issues on his Amazon Server, but not locally.
Some googling will also reveal that some folks have noticed that localhost handles things differently as well, so you may need to experiment around that.
Related
I'm found that request validation was not working on my PC, which meant it's behaving differently to our live web servers. After some experimentation it seems Glimpse is the cause (the version with Glimpse has not yet gone live, which is why the live servers were working normally).
e.g. this malicious URL:
http://website/?foo=<script>
...should cause the following error:
A potentially dangerous Request.QueryString value was detected from the client (foo="<script>").
However once Glimpse is registered in web.config "modules" section, the request validation doesn't happen (even when Glimpse is turned off), leaving the website open to cross site scripting attacks (XSS).
If I remove the line which registers Glimpse, then request validation immediately works normally: In in IIS 7.5 this is as follows:
<system.webServer>
<modules>
<add name="Glimpse" type="Glimpse.AspNet.HttpModule, Glimpse.AspNet" preCondition="integratedMode" />
</modules>
Is there a way I can fix this, or is this a bug in Glimpse?
Update 1:
I've now verified the problem happens if I do a fresh install of Glimpse into an unrelated project (running ASP.NET 4.5.1), so it is not an incompatibility with the original project. I did not change any settings, I simply installed it from NuGet and the problem was immediately apparent.
I've also noticed I turn glimpse off by setting <glimpse defaultRuntimePolicy="Off" /> in Web.config, then the request validation also then kicks in as normal.
The way that request validation works in ASP.NET is that the input is validated and an exception thrown only for the first call to Request.RawUrl, Request.QueryString, and so on. Glimpse looks up the query string early on in the request (from RequestMetadata.get_RequestIsAjax) and swallows the exception, so future calls to Request.QueryString in the same request context will not be validated.
FWIW, the ASP.NET team has disowned request validation. See https://learn.microsoft.com/en-us/aspnet/aspnet/overview/web-development-best-practices/what-not-to-do-in-aspnet-and-what-to-do-instead#validation for more information.
I have published an ASP.NET MVC3 site. It runs great. However, looking back at my web.config file, I was not sure if some of the values I used are correct for publishing versus for developing. These configurations are in the <system.web> section.
...
<system.web>
<httpRuntime requestValidationMode="2.0" executionTimeout="200" maxRequestLength="20000000"/>
<compilation debug="true" targetFramework="4.0">
...
I read here ( http://msdn.microsoft.com/en-us/library/e1f13641.aspx ) that using debug=true in compilation will disregard the executionTimeout of 200, and use a default value of 110. This seems to be the case, and the site is setup to allow very large amounts of files to be uploaded all at once. However, with only 110 seconds, not much can be uploaded.
My question is this: Is the correct setting to publish a live site for debug "false"? In addition, is requestValidationMode="2.0" still safe to use considering asp.net is now on version 4 (soon to be 4.5)?
Validationmode 2.0 is not the framework version and can stay like that.
Put debug=false and you are fine.
requestValidationMode... As far as I'm aware, this has to be set to 2.0 if you want to allow special characters (<, >, % etc.) in request data to pass ASP.NET's request validation at all. requestValidationMode="2.0" means "only enforce validation on pages (i.e. .aspx), rather than on every request (as was introduced in 4.0). That allows ASP.NET MVC to take over the validation - and hence also lets you turn it off for specific requests.
Is it safe? It is, if you've made sure that any actions or controllers that have [ValidateInput(false)] applied or models with [AllowHtml] have been properly secured against attacks. Imran Baloch has a full explanation here.
And yes, debug should be "false" for several reasons, including performance and memory usage. Also, debug="true" changes the default cache policy for static files to never cache the files in the browser, meaning tons of redundant requests for scripts, CSS etc.
As for the image upload, other than the suggestions given, check in Event Viewer that it's not really the application pool recycling for one reason or other, rather than an execution timeout.
I have an aspnet webapp which has worked very well up until now.
I was recently asked to explore ways of making it scale better.
I found that seperation of database and Webapp would help.
Further I was told that if I changed my session providing mechanism to SQLServer, I would be able to duplicate the Web Stack to several machines which could each call back to the state server allowing the load to be distirbuted better.
This sounds logical. So I created an ASPState database using ASPNet_RegSQL.exe as detailed in many locations across the web and changed the web.config on my app from:
<sessionState mode="InProc" cookieless="false" timeout="20" />
To:
<sessionState mode="SQLServer"
sqlConnectionString="Server=SomeSQLServer;user=SomeUser;password=SomePassword"
cookieless="false" timeout="20" />
Then I addressed my app, which presented me with its logon screen and I duly logged in.
Once in I was presented, with a page that was not with the page I was expecting.
I can change the sessionstate back and forth. This problem goes away and then comes back based on which set of configuration I use.
Why is this happening?
Nice error Dude :)
Probably a red-herring, but what are you storing in Session state?
When you move from InProc to SQL Server, the stuff you store in SQL must be Serializable (I think)
Use Fiddler to see what's really going on over the wire. To me it looks like your app is sending back an image when the browser is expecting HTML.
What is the fastest way to execute a method on an ASP.NET website?
The scenario is pretty simple: I have a method which should be executed when a web page is hit. Nothing else is happening on the page, the only rendered output is a "done" message. I want the processing to be as fast as possible.
Every single hit is unique, so caching is not an option.
My plan is to use an HttpHandler and configure it in web.config (mypage.ashx) rather than a regular .aspx page. This should reduce the overhead significantly.
So my question is really: Is there a faster way to accomplish this than using HttpHandlers?
Depending on what you're doing, I wouldn't expect to see a lot of improvement over just using an HttpHandler. I'd start by just writing the HttpHandler and seeing how it performs. If you need it to be faster, try looking more closely at the things you're actually doing while processing the request and seeing what can be optimized. For example, if you're doing any logging to a database, try writing to a local database instead of across a network. If it's still not fast enough, then maybe look into writing something lower level. Until that point though, I'd stick with whatever's easiest for you to write.
For reference, I've written an ad server in ASP.NET (using HttpHandlers) that can serve an ad (including targeting and logging the impression to a local database) in 0-15ms under load. I thought I was doing quite a bit of processing - but that's a pretty good response time IMHO.
Update after several months:
If you clear all the HttpModules that are included by default, this will remove a fair amount of overhead. By default, the following HttpModules are included in every site via the machine-level web.config file:
OutputCache
Session (for session state)
WindowsAuthentication
FormsAuthentication
PassportAuthentication
RoleManager
UrlAuthorization
FileAuthorization
AnonymousIdentification
Profile
ErrorHandler
ServiceModel
Like I said above, my ad server doesn't use any of these, so I've just done this in that app's web.config:
<httpModules>
<clear />
</httpModules>
If you need some of those, but not all, you can remove the ones you don't need:
<httpModules>
<remove name="PassportAuthentication" />
<remove name="Session" />
</httpModules>
ASP.NET MVC Note: ASP.NET MVC requires the session state module unless you do something specific to workaround it. See this question for more information: How can I disable session state in ASP.NET MVC?
Update for IIS7: Unfortunately, things aren't quite as simple in IIS7. Here is how to clear HTTP Modules in IIS7
I'm not sure what your exact scenario is, but if all your page is doing is processing some data, you don't really need an aspx page or an http handler at all. You could write an ASMX web service or WCF service to do what you need and this would most likely be less overhead. The WCF service doesn't even have to be hosted in ASP.NET. You can host it from a Windows service or console app, and call it in-proc using named pipes. This would probably reduce the overhead for calling the data processing code significantly.
If you really have to use asp.net, you can also just hook into AuthorizeRequest step and intercept the request from there, do your processing and write your Done response directly.
I'm trying to put in an exception in my web.config so that one page does not require authentication. However, it still redirects to the login page.
The question isn't how to setup the web.config. Why? Our system (for better or worse) has a bunch of instrumentation besides the web.config. We have global.asax and custom HttpHandlers. The code base isn't huge, but there's a lot of potential causes for the redirect.
What I do want to know is how to best determine the cause of the redirect. Is there some way to find out what code triggered the redirect?
If you can debug the app, starting from HttpApplication.BeginRequest in global.asax and stepping through System.Web's reference source would be the brute force way.
Alternatively, set a breakpoint on HttpResponse.Redirect(string, bool) and follow the call stack - I doubt there's any other ways that the runtime uses to redirect a request.
If that doesn't turn anything up (or you can't debug), and since the brute force method is likely to lead through a lot of code - and it seems your problem is security related - you could probably just hook HttpApplication. AuthenticateRequest and HttpApplication. AuthorizeRequest, (and it's associated Post* events) and seeing what things look like there.
If you're using Forms Authentication, I happen to know that the FormsAuthenticationModule looks for a status code of 401 at HttpApplication.EndRequest to decide whether to redirect the request. Anything that sets 401 (access denied) will result in a redirect - not the 401 being returned to the browser.
When a request is made to an asp.net page requiring authentication, asp.net redirects to the specified login page with supplying a ReturnUrl querystring argument identifying the original requested page by default. While this ReturnUrl is configurable, if you have not modified the configuration, it's presence should indicate that authentication failed.
In this case, you should be focused on troubleshooting the authentication settings for the page. Gordon Bell's answer looks good for this.
<system.web>
...
</system.web>
<location path="NoAuthNeeded.aspx">
<system.web>
<authorization>
<allow roles="*" />
<allow roles="?" />
</authorization>
</system.web>
</location>
Also, if this is only happening in your production app, you might be able to find out what is going on using WinDBG. Loosely following this article you'd do the following:
Fire up WinDBG and attach to the w3wp process
WinDBG will breakpoint, so do a .loadby sos mscorwks which will load the SOS module
type sxe clr to breakpoint on CLR exceptions
type g to continue on
Now your app will break on any exception. Since Response.Redirect typically throws a ThreadAbortException it might be a simple way to break. Then do a !printexception to get the stack trace. You can also do a ~*e!clrstack if my WinDBG foo isn't failing me to see the managed stack for all the threads currently executing.
Note that you freeze the w3wp process while you are broken in, so be quick!
Hopefully you can use another method instead, but if all else fails, this might help you get started.
Have you tried turning on Tracing? That may help.
How are you specifying the page doesn't require authentication, like:
<system.web>
...
</system.web>
<location path="NoAuthNeeded.aspx">
<system.web>
<authorization>
<allow roles="*" />
<allow roles="?" />
</authorization>
</system.web>
</location>
Put a breakpoint at the beginning of each HTTP handler and notice which one is the last invoked handler before the redirect occurs. You will probably find the cause of the problem in that one.
You can use the following method to find a redirect in your own code:
Open the Exception Settings window and search for "threadabort". Check the checkbox for the ThreadAbortException. Now, when a redirect is executed from code, your debug session will enter break mode.
But since you are talking about the authentication in the web.config, it's highly likely that the issue is there, and not in the code.
Double-check that all the authorization elements like mentioned in HectorMac's answer are correct.