I've got a page with a large viewstate that appears to be tuncated during postbacks on one of our client's server. We will minimize this in the next release.
I'm trying the maxPageStateFieldLength page attribute in web.config, but it looks like this attribute is ignored. Viewstate size is larger than the value in bytes placed in this attribute, so the viewstate should be chunked in multiple input fields, but the page is generated with a single input field.
server is 2003/IIS 6, using compression.
Naming the attribute with an uppercase M triggers an error, so i know that it is recognized (with lowercase m) but asp.net does no chunking.
It is working with the same application under VS 2005 using internal web server on my dev machine.
Any idea what might cause this attribute to be ignored?
This link explain the behavior described in my last comment. Precompilation to a non updatable web site hardcode some page parameter values in the assembly, like theme, and i just found out, viewstate chunking
Related
Using: Visual Studio 2010 with ASP.net 4.0
I have a website which uses URL rewriting and I want to keep the rewritten URL on Postback. I've read a lot of the topics on this subject and I still haven't been able to figure out if this is possible.
For example:
http://localhost/ActualPage.aspx?PageID=4
Is rewritten as:
http://localhost/member/forum.aspx
The page contains a number of controls which use a Postback (for example a Telerik RadGrid with sorting and paging). Normally when the postback takes place the browser is redirected to the unrewritten url - the address bar shows /ActualPage.aspx?PageID=4 etc. In this scenario everything works correctly.
However I want to retain the rewritten URL after the postback, so I have coded to change the Form.Action property to be the rewritten URL like so:
Page.Form.Action = "/member/forum.aspx"
Now the page correctly retains the URL in the address bar but throws a "Validation of viewstate MAC failed" error when the postback occurs - which I would expect it too as the viewstate originated from a different URL.
Strangely this problem occurs even when enableViewStateMac is set to false (either in the page or in the web.config) - but I don't want to disable this anyway.
Effectively I think what I need to do is tell the page / viewstate mac authorisation that is it ok to accept input from this alternative URL but I can't find anyway of doing this. I've tried different URL rewrite system to see if that makes a difference, and i've tried added a generated machineKey - neither of which has made any difference. Is there any way of doing this?
In short I want:
Rewritten page with postback going to the rewritten URL
ViewStateMac enabled
No viewstate validation errors
I remember in earlier versions of .NET using a .browser file with FormRewriterControlAdapter but this doesn't seem to make any difference in .NET 4 (I don't remember if it successfully retained the URL anyway).
I have found a solution - it turns out the problem was actually unrelated and masking itself as a ViewStateMac issue.
Previously I had been redirecting all the URLs to one page, doing a database lookup and then using Server.Transfer() to deliver the correct page to the browser. The real problem was being caused by using Server.Transfer() - which it seems is recognised by Microsoft to be an issue when working with the viewstate.
I have made adjustments so IIS performs the database lookup, the entire rewrite and therefore Server.Transfer() is not used - and the original problem I had has been resolved.
We have been trying to figure this one out for a while now, without any luck.
The symptoms are as follows:
After some idle time of a specific ASP.NET 2.0 application (can be from several hours to days), one of the pages in my application stops working.
When viewing the source of the page I see many elements missing, elements that are usually there, such as: reference to WebResource.axd, the __doPostBack() function, all of the UserControls and more.
A reference to ScriptResource.axd, and the __VIEWSTATE are there.
After recycling the app pool, the application starts working correctly again and everything renders well.
This only happens on a specific server, when deploying the same application on a different server, this error does not occur.
The page that the error occurs on has only one UserControl which is not rendered when the error occurs. Nothing special happens when this page is loaded.
We tried doing periodic client refreshes, but that did not help either.
Thanks in advance.
It was a caching issue. There was a part in the code that hid specific controls when the cache was invalid. That explains the missing code parts.
I am still not sure why the cache was invalid on that specific server.
I'd like to let my user add HTML to an entry in a SQL Server table using the CMS, but I keep getting the warning:
System.Web.HttpRequestValidationException: A potentially dangerous Request.Form value was detected from the client (ctl00$MainContent$TextBox2="<p>We...
What is the best way to allow HTML to be added to my CMS?
Many thanks
You can enable/disable request validation on a per control, per page, or on application level.
See http://www.asp.net/learn/whitepapers/request-validation for more info.
Be aware that if you're using asp.net 4.0 you might have to set the requestValidationMode as well (see ValidateRequest="false" doesn't work in Asp.Net 4)
ASP.NET automatically tests forms for input of potentially dangerous characters (pretty much anything HTML...). To get around this you can ValidateRequest="false" at either the page or app level (in web.config), but then you will need to manually clean the HTML yourself to ensure that no malicious code is injected. The best article on code cleaning I've seen is http://wonko.com/post/html-escaping .
Around 90% of the pages for our websites have no .Net code embedded in them yet are published as .aspx files. I want these to render as fast as possible so I'm removing as much as I can.
Does the .Net page directive have an impact on performance? I am thinking about two factors; the page speed for each GET and what happens when the file changes. The CMS system re-creates each page daily and I'm wondering if this triggers the ASP.Net compilation process.
If your pages have no .NET code and rendering speed is your goal, you may wish to consider changing the extension to .html. Any .aspx page will be passed to the .NET ISAPI filter by IIS and go through the entire chain of HttpModules, then will be handled by the Page HttpHandler. Using a .html extension would trigger IIS to process the request using the Static Resource ISAPI filter, which has a much shorter pipeline and is tuned for resources that run no code.
The <%# Page %> directive is not required. Without it, the default values for Language and other stuff will be assumed.
By changing a .aspx file, it'll be recompiled (it doesn't recompile the whole app though):
Any changes to a dynamically compiled file will automatically invalidate the file's cached compiled assembly and trigger recompilation of all affected resources. The next time a request to the code is made, ASP.NET recognizes that the code has changed and recompiles the affected resources of the Web application. This system enables you to quickly develop applications with a minimum of compilation processing overhead. (Note that depending on the change to the resources, the result can range from recompiling a single page to recompiling the whole Web site.)
Ok, put them in - just to be sure.
.NET pages are ALL compiled, page directive or not. nothing changes. Post compilation, they are as fast as it goes, as they turn into a class (type loaded once) that just executes.
Note that the post by Mehrdad Afshari is factually wrong (sadly I can not tag it). Any page change triggers a complete recompile AND restart of the appdomain. Acutally any FILE change does so, as long as it is outside App_Data and ASP.NET can see it (i.e. non-hidden flag on the directory / file).
My asp.net 2.0 web site generates text files. Sometimes these files can get quite large. Under most cases the files are presented to the user, and approved without modification. However there are times when the end-user has to make changes to these files and submit the changed version back to the system.
Currently, when a file needs to be changed, I load the text into a textbox control, and I rewrite the file on postback. However I'm running into problems with OutOfMemory exceptions, invalid viewstate, etc.... These problems only occur when the file generated is large.
I beginning to think that I need another strategy for editing these files, but I'm at a loss as to which direction to take. Is there an ACTIVEX control that would serve me better? Should I abandon server side controls for this interaction and just deal with plain vanilla http posts?
Thanks in advance.
I am not sure about an activeX control, but you could use Silverlight. Thsi would allow you to stream the file to th Silverlight control, and then it could be edited on the clints machine, and when they are done, the chnages are sent back and stored by the server.
However, you will need to have .Net 3.5 on the server and make some changes to the web.config inorder to build against the 3.5 framework. If this is not acceptable, but you like the idea of doing stuff on the client side, you can also try using flash.
One suggestion to consider would be an ajax call to a pagemethod that way you could just post the text file to the server without posting the whole page and the associated viewstate.
Can you break up the text files into sections and allow the users to submit changes one section at a time?