Whenever RewritePath() is called, Page.IsPostBack is false

Question

I'm developing a custom URL Rewriter for a ASP.Net 3.5 project. This rewriter is not functionally different than most rewriters out there, the only difference being that the friendly URL collection is not loaded from a web.config file -- it's coming from a database instead. I made the naive assumption that it would be easy to develop a custom rewriter module from scratch, but now I know the mess I put myself in. I digress; let's go straight to the technical issues.

While testing the rewriter, I set up a friendly url that would take the user to a web form. Postbacks from this form should not alter the friendly address, as anyone would expect, so

http://my.web.site/app_root/FriendlyURL is always rewritten as http://my.web.site/app_root/not_friendly/form.aspx

Things are fine when the browser first loads the FriendlyURL. The page comes up and is completely functional. However, when the form is posted back to the server, the page simply reloads but, at server-side, IsPostBack is false. It's like F5 was hit, except that a HTTP POST had indeed occurred.

Unsurprisingly, when the interaction occurs through the "unfriendly" URL, the POST action triggers the postback as expected. This evidence suggests that HttpContext.RewritePath is somehow messing with the page lifecycle in a way that it loses sense of the postback operation. Any directions? Thanks.

Answer 1

Thanks to StackOverflow, another nearly-duplicate problem gave me hints about the core issue. In short,

Server-side components that set the PostBackUrl attribute mess up with path rewriting system during postbacks. Or the postback system is messed up during the path rewrite. (The causal relationship is unclear, but the effect is what I described in the question.)

Any asp:LinkButton, asp:Button or asp:ImageButton that sets PostBackUrl (either at form, master page, or user control levels) will cause web forms to include a __PREVIOUSPAGE hidden element whose contents are opaque, but it has some role during postbacks. This was my problem: there were several asp:LinkButtons that set the PostBackUrl attribute.

When the page (form + master page + user controls) is free of PostBackUrl 'd elements, __PREVIOUSPAGE disappears and the postback mess up is gone. So after I reviewed each asp:LinkButton in the entire site, and transformed them into ordinary <a> elements, the problem was solved.