SavePageStateToPersistenceMedium In HTTPModule.

wonkoTheSane

Hi.

Im looking for some info, the basic issue is that we have an app which we do not control the source for which has very large viewstates...
We would like to create a module which will override the SavePageStateToPersistenceMedium method and store the viewstate data in the cache object.

Does anyone have any info on that? Is it possible? If not is there another way that you can suggest that may work?

Cheers

fyjham

It's definitely quite possible to change what gets rendered into the viewstate, and so long as you override the methods that pull it back out you can do so seamlessly. I've used this previously to gzip the viewstate, but if you wanted to put an index in the viewstate and look it up from somewhere later there's no reason it wouldn't work. I'd question using the cache - given it could easily be cleared before the user returns, and I'd recommend at least some effort to avoid a user faking another's viewstate ID - but there's nothing fundamentally impossible about the concept.

Be sure to get the right save/load functions - there's more than one spot you can do it and some don't work with .NET AJAX. I don't recall exact methods but if you'd like I can track down that gzip code and post a snippet that'd help you on your way?

fyjham

Hey,

Just grabbed that snippet for ya. This is something we use to compress the viewstate and we've been using it for a few years now across multiple sites with no real issues. Ours is overridden in a Page class that we use that all our pages inherit from not in a HttpModule though... The compression/decompression stuff references some of our internal libraries that I haven't included, shouldn't really need that part though if you're going for storing it server-side.

        protected override object LoadPageStateFromPersistenceMedium()
        {
            string viewState = Request.Form["__VSTATE"];
            byte[] bytes = Convert.FromBase64String(viewState);
            bytes = Anonymized.CompressionTools.DeflateDecompress(bytes);
            LosFormatter formatter = new LosFormatter();
            return formatter.Deserialize(Convert.ToBase64String(bytes));
        }

        protected override void SavePageStateToPersistenceMedium(object viewState)
        {
            LosFormatter formatter = new LosFormatter();
            System.IO.StringWriter writer = new System.IO.StringWriter();
            formatter.Serialize(writer, viewState);
            string viewStateString = writer.ToString();
            byte[] bytes = Convert.FromBase64String(viewStateString);
            bytes = Anonymized.CompressionTools.DeflateCompress(bytes);

            ScriptManager.RegisterHiddenField(this, "__VSTATE", Convert.ToBase64String(bytes));
        }

wonkoTheSane

Hi sorry for not replying sooner.. for some reason I didnt get an email when you replied despite the email subscription being on... so I didnt think anyone had responded.

I know that it is possible, infact the code that you have posted is similar to something that we have already done in one of our own apps, the issue is that this is an app that we do not have the source for so we need to impleemnt the changes as a module, and thats the bit that Im struggling with LoadPageStateFromPersistenceMedium can be overridden in the page, but in an HTTPModule?

Basically thats the issue, however luckilly this is no longer as urgent a requirement so I dont NEED to know, but it does bug me that I couldnt do it, so I would still like to know if anyone has any ideas!

Thanks

RaspenJho

Viewstate is just a hidden form field with base-64 encoded data in it.

Couldn't you just intercept the post, inspect whether the Viewstate form field has a surrogate key in it, and if so, substitute the actual Viewstate data for the key, and rewrite the value before the page gets loaded?

I agree with the previous poster about using Cache for this though. Cache (implemented properly) is never guaranteed to contain anything.

Jaime

Careful... Turning page state into session state can break an application in entertaining ways. After you implement this, I dare you to open a page in the web application, open a new web browser window (which clones the current window), and start interacting with both windows. Page state is really nice because the client will keep it for as long as necessary without taking any server resources. If you move it to the server, it can be very difficult to decide how long to keep it around. The only safe answer is to keep the state of every page for a session until the session ends. You could easily end up with a web application that requires a gigabyte of RAM for every five concurrent users.

wonkoTheSane

Thanks for the answers that have been given this is all wrapped up now, as I said its not an app that we have the source to change, so we are kinda linited in what we can do, the main issue with the app at the moment is that on average the viewstate is 300Kb + Thats a hell of a lot of data to send/recieve on EVERY post.... I know its not a great solution (Its not actually even a real solution to the root problem) but we can always add more memory... Increasing the bandwidth that end users have available to make sending the viewstate back and forward faster.. thats not something we can do!

Thanks again

PS. Why TF dont the email notifications on these forums work? (Dont answer I know the answer is community server!)