I have an issue where adding this to any asp.net request causes and unhandled error (regardless of CustomErrors setting): ?aspxerrorpath=<script
The weird thing is that I have two applications that are totally immune to the problem, but I can't spot the difference. I'm running on IIS 7 and using the 4.0 Framework. But this also happens on my 3.5 IIS 6 apps. Again, I have two sites that are fine (IIS 7, 4.0) but can't determine why. I have tried turning off request validation to no avail. Has anyone encountered something similar?
FIXED:
This looks like it was an Umbraco issue. It was ignoring my validateRequest="false" in the web.config. Adding this to the template fixed it:
<umbraco:DisableRequestValidation runat="server"/>
This looks like it was an Umbraco issue. It was ignoring my validateRequest="false" in the web.config.
Adding this to the template fixed it:
<umbraco:DisableRequestValidation runat="server"/>
In your section, ensure the following is set:
<pages validateRequest="false">
Related
I have a website which is hosted on GoDaddy they have version 4.0 runtime.
The issue is the client id of the server controls are generated as "contentPlaceHolder1_drpBanks" where it was earlier (when the website was on some other server) getting generated as "ctl00_contentPlaceHolder1_drpBanks".
What I need to know is there a way to resolve this so that I don't have to make any changes in the code.
Like a setting in web.config file or something.
In the future use <%=Control.ClientID%> which will successfully resolve every time - without code changes.
Controls in ASP.NET 4.0 have a ClientIDMode property. If you set this to AutoID, ASP.NET should generate client ids in the same way it did in ASP.NET 2.0. Here's an article that explains the different client id modes.
Besides setting ClientIDMode at the control level, you can also set it at the page or application level:
<%# Page Language="C#" ClientIDMode ="AutoID" ... %>
or
<system.web>
<pages clientIDMode="AutoID" />
</system.web>
But I agree with leppie's comment that it is dangerous to rely on generated client ids.
.NET 4 broke ValidateRequest=“false” for some reason.
The solution is -- just put <httpRuntime requestValidationMode="2.0" /> into your web.config file.
The problem with that solution is that it breaks support for .NET 2.0!
IIS refuses to accept unknown attributes in web.config. Also I don't like the all or nothing nature of this.
Can I set requestValidationMode (or in some other way disable request validation) for a single page that needs it? Without breaking backwards compatibility of web.config with 2.0?
I can confirm that the approach of adding validateRequest="true" to the web.config file works and it is marvellous!
Using this makes the page-level directives work correctly again and it avoids the need to change the behaviour back to the ASP.Net2.0 mode.
Strange that it has any effect, seeing as request validation is normally enabled by default anyway, but no matter.
if you are using .net4 then add this line to web config
<pages validateRequest="false">
and no need to use <httpRuntime requestValidationMode="2.0" /> at all
OK, looks like this can't be done and I can just escape the data easily, but I think this was a legitimate question -- at least to make a note here that this can't be done.
I found a better way, I think. I didn't like the option of reverting back to a 2.0 setting while in 4.0. I also don't like the all or none option.
I played around with a few things and I have at least in my mind a practical solution.
By default all pages are validated regardless of the page directive of "ValidateRequest="false"
I found where to make this setting in the web.config in the system.web section called pages.
(http://msdn.microsoft.com/en-us/library/system.web.configuration.pagessection.validaterequest.aspx)
If the validateRequest attribute is added into the pages element you can control the validation for the whole site.
But I stumbled across a happy thing while testing this. I couldn't find docuementation for this, but here is what I've experienced.
By default validation is turned on everywhere, but if I set the validateRequest to "true" my individual page directives work as they did in 2.0. I don't know why, but I'm happy.
So in summary...
Set the validateRequest to true.
Like here.
Then any page directives work for that validation.
I just put this in my web.config in the system.web node.
<httpRuntime requestValidationMode="2.0" />
I've used the UrlRewriting.Net module for a couple years now without any problems in Windows XP and Windows 2003. I just recently upgraded my home PC to Windows 7 and started developing a new website.
The plan was to use .html extensions and rewrite them to their .aspx counterparts using the UrlRewriting.Net module. Everything works flawlessly in VWD 2008, but when I try running it through IIS7 it is a different story.
When I try to access a page via the .html rewrite I can no longer access Page.User; it keeps returning null. If I hit the page using it's .aspx extension, Page.User is correctly populated. I should also mention that I have a LoginView controller in my Master Page and it suffers from the same symptoms: When accessing via .html extension it shows the AnonyousTemplate; When using .aspx extension it properly shows the LoggedInTemplate. I'm guessing the two are related.
[Note: I've also tried extensionless URLs and they exhibit the same problem]
The only way I've gotten it to work is to switch the application pool to Classic, which then requires me to add an ASP.Net ddl handler for the .html extension [otherwise it is handled by the StaticFileHandler and comes up as a 404 error]. However, I'd like my web app to run properly for people without having to fiddle around with IIS.
So I am left with several questions:
Does anyone have ideas as to why Page.User always equals null for .html => .aspx rewritten pages?
Why does it work in VWD 2008, but not IIS7?
What changed from IIS6 => IIS7 that could have caused this?
Any other thoughts on workarounds?
[Note: I just tried a .aspx => .aspx rewrite and it did not exhibit the problem. Not really what I want, but thought I should mention it.]
Just had a breakthrough with the UrlRewriting.Net module. This makes it work in Integrated Mode in IIS7:
<modules runAllManagedModulesForAllRequests="true">
After figuring it out I did a search on "runAllManagedModulesForAllRequests" and the first thing that popped up was Scott Guthrie's blog which actually talks about using it for this purpose.
Another approach that seems to work is to remove the Session module and readd it leaving the "Invoke only for requests to ASP.NET applications or managed handlers" checkbox unchecked. It looks like this in the web.config file:
<system.webServer>
<modules>
<remove name="Session" />
<add name="SessionManualAdd" type="System.Web.SessionState.SessionStateModule, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</modules>
</system.webServer>
It seems the problem is that the Session module doesn't execute for say '*.htm' files when HttpContext.RewritePath is used, but removing and readding the module in this fashion causes the Session handler to be executed for the request.
This solution was suggested on the thread below. Unfortunately Microsoft chose not to explain the reasoning behind this behavior fully:
http://connect.microsoft.com/VisualStudio/feedback/details/357248/context-rewritepath-disables-session-module-in-iis7
Microsoft included a fix for this issue (at least for extensionless urls) in Service Pack 1 for Win7 and Windows Server 2008 R2:
http://www.microsoft.com/download/en/details.aspx?id=5842
Also available as a hotfix: http://support.microsoft.com/kb/980368
After this patch is applied, ASP.NET 4 applications can handle requests for extensionless URLs. Therefore, managed HttpModules that run prior to handler execution will run. In some cases, the HttpModules can return errors for extensionless URLs. For example, an HttpModule that was written to expect only .aspx requests may now return errors when it tries to access the HttpContext.Session property.
After applying SP1 or the hotfix, no web.config changes are needed to make the session and forms auth work for extensionless URLs rewritten to asp.net pages/handlers/etc.
I don't know if this fixes anything for rewrites to static file extensions like .htm. My guess is, probably not. I would try to avoid setting runAllManagedModulesForAllRequests="true" in production environments, because it adds unnecessary overhead on static file requests.
setting maintainScrollPositionOnPostback="true" globally in web.config does work in my xp sp3 under iis 5.1 but not for production server(win server 2003 sp2 with .NET 3.5 sp1 and IIS 6).
but if add MaintainScrollPositionOnPostback="true" for any <%# Page directive it is working like a champ.
I don't know if I should add clear tag for web.config to override it in IIS 6 or something?
Any Advice,tips or comments would be Appreciated
here is the related section in web.config
<pages maintainScrollPositionOnPostBack="true" validateRequest="false" enableEventValidation="false" viewStateEncryptionMode="Never" enableViewStateMac="false" >
<controls>
....
</controls>
</pages>
--------update---------
I don't know what was the real problem then when i post the question ,right now i have no problem with maintainScrollPositionOnPostback=“true” in my new system with windows 7.
might be a problem with case sensitivity - try maintainScrollPositionOnPostback (lowercase m)
I had similar problem. But after inspecting markup found out problem was with one of the update panel. Check update panels if you have similar problem.
Hey i found solution on Javascript file
Just add in your header file after jquery library
I think this will resolve your problem its works perfect for me.
We are using the Intelligencia URLRewriting module for asp.net with version 2.0 of the framework and IIS6. Our URLs typically have no extension.
I understand that IIS6 cannot really deal with this situation without a blanket wildcard (which causes other problems).
However, it works! Sometimes. At other times (e.g. on one dev's machine, and on my machine when I point a different virtual directory at the app) it doesn't. By "it doesn't work" I mean the configured HttpModules never even get hit.
Can anyone explain this?
Thanks.
So it turns out what was happening was the following:
request comes in to (say) http://website/products/productid
IIS can't find this hence we get a 404
by chance we have a custom error page set up in IIS for 404s
this error page sticks the referring URL on the end of the 404 error.aspx page
so we get a redirect coming into asp.net along the lines of:
http://website/error.aspx?404;http://website/products/productid
our URLRewriting regexes were now set up in such a way that they discarded the error.aspx bit and dealt with http://website/products/productid as if it were the actual URL
so asp.net renders http://website/product.aspx?id=productid as requested!
I guess this could prove to be a useful kludge for someone, but we're moving to an isapi filter. One heads-up is that this will by default lead to a tight loop of redirects!
If you run a site using the Visual Studio development web server all requests will be handled by asp.net so your HttpModule will run.
On IIS6 this should not happen unless it is set up to forward the requests to asp.net.
Are you sure that when "it works" you aren't running under the Cassini development web server included in VS.NET ? Because extensionless wildcards do work under Cassini, which can be very confusing to say the least.
If you are using an IIS6 with ASP.net 4.0, you must specify and register the modules like this:
<system.web>
<httpModules>
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
not
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<add name="UrlRewriter" type="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
</modules>