.NET ViewState and IsPostBack problems
Posted on 2005-05-06
I've got a problem that has given me manny headaches already and still no solution is on sight. This is also quite urgent since the site sgould be published already.
We're using the ISAPI Rewrite to produce human readable URLs. The first problem was, that when a postback happens the url in the browser address gets concated with the previous one, thus concurent with multiple postbacks it gets larger. This not only couses ugly and non-human-readable address but also couses and invalid address and invalid request parameters.
When I found out that one can't change the HtmlForm action attribute, which was obviously a problem in one of the article I found that I can write a custom HtmlTextWriter and use that in the overriden method of the System.Web.UI.WebControls.WebPage Render method. This is working like a charm - the rendered html form action property contains the human readable address that is seen in address field of the browser after postback.
But here is where the problems started. In order to avoid ViewState errors (after reading a few articles) I had to set the EnableViewstateMac="false" in the web.config. This solved the "Viewstate might be corrupted" error but it couses the normal ViewState not to load anny of the values. I checked the "__VIEWSTATE" property of the hidden form field and it's fine, but the ViewState still doesn't get loaded on postback.
I was whondering it it was the ISAPI rewrite problem with headers. I checked and when a postback should happen the METHOD is indeed POST. Another problem is the Page.IsPostBack is always false - probably because of the ViewState.
I forgot to mention the flow that a request goes through after the Rewrite rules are applied. First the request is hanled by the default.aspx page. When it finds out which page to display it checks for its template. A template has nothing to do with .NET templates but it is a normal .aspx page except it inherits from a line of parents for presentation layer. So the default.aspx uses Server.transfer (this might also be a problem) to redirect the Request to that page since the Response.Redirect messes up the browser address box and all. I tried Transfer with false and true parameters - but it doesn't really matter if the state is preserved - in every case the result is the same.
After trying almost everything from Microsoft bug reports and much other articles this still remains a major problem in the app so I'd be really, really gratefull for any sensible and save solution.
Thanks in advance,