Hi John,

I don't know anything about 51degrees, but I can say that it is normal for your home page to work with 3 different urls

yoursiteroot/

yoursiteroot/home.aspx (assuming that home.aspx is the defined url for your home page)

yoursitesiteroot/Default.aspx

and postback could occur and should work correctly for any of those 3 possible urls. I don't know why you would expect anything different for the first variation of the url. There is a bug in VS web server where an error can happen in the first variation but there is no bug in IIS, that url is supposed to work for postback.

Just taking a quick look at 51degrees I see it is an httpmodule plugged into web.config. I would think it matters in which order the httpmodules run so the position of the declaration for it would be important. I'm not sure wheether it should be before or after our mojoUrlRewriter module. If it needs to run first then it should be above our module or if it needs to detect the rewritten url then it should be after our module.

Hope that helps,

Joe

Hi John,

So now it sounds like it isn't even related to 51degrees since you removed it from the equation and the problem still happens.

Are you sure its related to recent mojoPortal updates? ie did you upgrade recently and it started right away after that?

My guess is it is more likely the result of changes in a recent ASP.NET security update.

Are you seeing any errors in the log?

The ASP.NET security update set a limit on the allowed number of form elements and your home page has a lot of them so it seems likely a factor. I encountered an error on this site after the security update when I went to save site settings. It turned out to be caused by having too many form elements because I had a lot of roles and the permission tab has about 10-12 checbox lists populated by all the roles and combined with all the other form elements on the page it all added up to more than 1000 form elements which is what the new security update set as a limit. I solved it temporarily by removing extra roles that I was not using, and I have since solved it in our source code repository by moving the permissions out of site settings into its own pages such that only one permission is updated at a time so even with a lot of roles it doesn't add up to that many form elements.

There is another workaround you can try as mentioned in the post by Scott Gu linked above, you can add this in your user.config file

<add key="aspnet:MaxHttpCollectionKeys" value="1500"/>

You may want to experiment with that and try higher numbers like 2000 and if that solves it back it down as much as you can without restoring the error.

I don't see why it would be browser specific though if it is caused by the ASP.NET security update changes, but your home page does have a lot of form elements so that would be my first guess.

Hope that helps,

Joe

Hi John,

You could try solving it like this:

if(Page.Form.Action.Length == 0) { Page.Form.Action = "/Default.aspx";}

Hope that helps,

Joe

Hi John,

The runAllManagedModulesForAllRequests attribute when set to true enables the use of extensionless urls. So, if you are not using extensionless urls you can remove that with no problems. We did change in some recent version to enable that by default since most people are using  IIS 7.x nowadays. In a nutshell what that does is make .NET httpmodules execute for all requests not just for extensions mapped to .NET like .aspx, .ashx etc, but all requests even for static files, the .NET httpmodules will participate in the request. So it makes it possible for our urlrewritermodule to rewrite requests with no extension like /home instead of /home.aspx to /Default.aspx?pageid=x. Otherwise our module would not execute for requests like /home

I did recently notice something in mojoBasePage that may explain why my suggestion about changing the form action from server side code didn't work. We are injecting some javascript that is meant to solve a problem with ajax postbacks right around line # 1383 in mojoBasePage. The javascript is setting the form action to match the url so it may be defeating the server side code that is setting the form action to /Default.aspx.

I've since wrapped a web.config setting around it so it is possible to turn that off. You could try commenting it out in your copy if you are not using the latest code from the repository, or just remove the runAllManagedModulesForAllRequests as you have done.

Best,

Joe

Hi John,

Thanks for that! Extensionless urls does seem to work without enabling runAllMangedModulesForAllRequests if I set preCondition="" on the module itself. However I think it is really doing the same thing as runAllManaged modules but doing it on a module by module basis, so setting them all to preCondition="" is probably about equivalent to using runAllMangedModulesForAllRequests="true".

Best,

Joe