Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


.NET ViewState and IsPostBack problems

Posted on 2005-05-06
Medium Priority
Last Modified: 2008-01-09
Hi experts.

    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,

Question by:TheBoogie
LVL 23

Accepted Solution

b1xml2 earned 1500 total points
ID: 13945693
whenever a Server.Transfer occurs, the page to which the transfer occurs will always register as though it was loaded the normal way (IsPostBack = False),There's nothing wrong with this.
In the Server.Transfer method, you can specify whether you want to pass the Request.Form collection through

Thus assuming the page the transfer is going to is say PageB (and assuming you are using VS.NET )

Private ReadOnly Property IsServerTransfer() As Boolean
    Return (Context.Handler Is PageB)
  End Get
End Property

private bool IsServerTransfer
  get { return (Context.Handler is PageB); }

so even if the IsPostBack returns as false, you have the unique situation of having the Request.Form collection available.

You can access the controls in PageA like so

The Context.Handler in a Server.Transfer is always the original page.

Author Comment

ID: 13955109
b1xml2, thanks for your response but this is not exactly what I wanted to do. What I wanted was to simulate a situation in such a way, so that ASP framework would load the viewstate and all other asociated variables the same way as if all the requests went throught the same aspx.

Here's the situation. We have decided to make user controls (ascx) instead of secondary or PageB pages as you call them so that all the server - client communication goes throught the same page. Had to do this in order to meet the deadlines. But I'm still going to leave the question open in case someone else has the same problems.

The situation was: there was a page, called default.aspx as common in .net web applications. This page had to do some initialization and then pass the task of generating a response to template aspx files. At first we were using Response.Redirect which worked as expected - no ViewState errors and also PostBack worked OK. The only problem was that when a page got redirected the url in the client browser got changed to actual virtual path. That was unacceptable since one of main features of the app was human readable URLs, done with ISAPI Rewrite.

At least I now understand what's happening behind the scenes in .NET when a page is loading. Anyways - the next step was introducing the Server.Transfer as it difers from Response.Redirect by not sending a command to the client to load a different page but passes control to the specified target directly. At the time I was implementing this I was unaware of the ViewState error (Microsoft confirmed bug) coused by the Server.Transfer.

I somehow managed to get this working by disabling the EnableViewstateMac for all the involved pages. Another problem was that when a POST method would happen from anny site this would mess up the human readable URL again, because of the ASP framework hardcoding the value of action in FORM html tag. I managed to override this by implementing a custom HtmlTextWriter. OK, now the page was submited to the correct rewritable URL, which got rewritten to the default.aspx. The default.aspx knew which template (aspx) to use the Server.Transfer with. But here the problem occurs with the ViewState not being loaded and the Page.IsPostBack property always being false.

So what I'm asking is - is there a way to make the ASP framework think it's loading the same page while actualy loading a completely diferent form? I'm aware of the second parameter to Server.Transfer. But when using lets say:

Server.Transfer("PageB.aspx", true);

all posted content is well available from the PageB. If U debug the OnInit method or any method further there's also a parameter "__VIEWSTATE" which is a key generated from Machine.Config. But the viewstate still doesn't get loaded. I tried replacing the value of the "__VIEWSTATE" with the key generated for default.aspx, but same result.
What I want to achive is to pefrorm kind of a hack to the framework and to be able to work normaly from any point beyond this without introducing anny extra variables.

By the way - b1xml2, thanks for your Context.Handler direction. It gave me something to work with, so I'm submiting the points to you.

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Q&A with Course Creator, Mark Lassoff, on the importance of HTML5 in the career of a modern-day developer.
Ready to get certified? Check out some courses that help you prepare for third-party exams.
This tutorial walks through the best practices in adding a local business to Google Maps including how to properly search for duplicates, marker placement, and inputing business details. Login to your Google Account, then search for "Google Mapmaker…
The viewer will get a basic understanding of what section 508 compliance can entail, learn about skip navigation links, alt text, transcripts, and font size controls.
Suggested Courses
Course of the Month11 days, 8 hours left to enroll

564 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question