Sitecore: Turning on HTML Caching blocks postback behavior

I have a sitecore page with an ASP dropdownlist, and the data on the form is populated from the selected value of the dropdown. When the selected item of the dropdownlist is changed, a postback is fired. In the postback, the new selected item is added to the querystring and the user is redirected (for linkability).

I recently enabled HTML caching (for all sublayouts, "Vary by querystring"), and now suddenly, this mechanism no longer works. What seems to happen is I select a new dropdown item, the page appears to post back (though if I'm debugging, none of my breakpoints get hit). After that, if I change the selected item aga开发者_如何转开发in, I can see in Firebug the message "__doPostBack is not defined", which appears to mean the ASP-generated JavaScript is not being added to the page.

Enabling caching for a sublayout means you are bypassing the code entirely and Sitecore is just serving up the same HTML it generated previously. So it's behaving as designed. In other words, this does not seem to be a scenario where you can take advantage of sublayout caching.

As posted previously, this is expected behavior precisely because the page is being fetched from the cache. You can still support caching for non-postback loads, but the easiest way I've found is to sense the postback with code in Global.asax and switch accordingly, as in the sample below.

    public override string GetVaryByCustomString(HttpContext context, string custom)
    {
        if (context.Request.RequestType.Equals("POST"))
        {
            context.Response.Cache.SetNoServerCaching();
            return "POST " + DateTime.Now.Ticks + " " + context.Request.RawUrl;
        }

        switch (custom)
        {
            case "RAWURL":
                return context.Request.RawUrl;
            default:
                return "";
        }
    }

Then you can hook this to output cache directives in your controls:

<%@outputcache duration="3600" varybyparam="none" varybycustom="RAWURL" %>

Note that if you do it this way, you lose the easy ability to vary by a control's data source.