The Reason For All Human Existence
We have a HTTPModule which rewrites .html file extensions to .aspx. The aspx file is served but the user sees the URL as .html. This apparently gives us mega Google points which is fundamentally the reason for all human existence and therefore intrinsically justified.
Form Action Attribute: Enemy of Civilisation
The HTTPModule does the URL Rewriting via HTTPContent.Current.RewritePath(realfilename.aspx).
This leaves the the URL that appears in the browser untouched but causes realfilename.aspx to be served to satisfy the Page Request.
BUT RewritePath sets the underlying Form Action Attribute is also set to realfilename.aspx which means that on Postback realfilename.aspx is POSTed to and realfilename.aspx appears in the Browser Address Bar. This drains Google Juice and makes life, work and all existence meaningless. Worse still , the behaviour of the web page was entirely accurate. The page does need to post back to the real page (not the fake one) in order to process the Postback. That happens through the Form Action Attribute: that’s what its for.
False and True Friends
The #1 recommended solution to this problem on teh Greater Google is to remove the Form Action Attribute entirely from the page by implementing a custom HTML Form Control and overriding the Render method. Once this is done, the Form apparently posts back to the URL in the Address Bar. But I didn’t want to mangle my page that way as it leads to downstream problems and besides, I really did need to postback to realfilename.aspx.
Examining one of our existing Web Pages that handled this scenario correctly, I noticed the form was wrapped in an AJAX UpdatePanel. Yeah, that made sense, the full postback would be suppressed maybe changing some behaviours, so I did the same thing – but no bananas – still the postback put realfilename.aspx in the Browser Address Bar.
I then unleashed Firefox’s glorious FIREBUG to have a closer look at the requests generated on the existing good website and the new bad website. The Net Panel showed me that a POST operation was appended to the list of Requests for the page, while on the bad website a brand new GET was invoked, in Firebug’s Net Panel the GET would clear all the entries and repopulate it with entries with the fresh Request. Suck.
An even closer look at the existing website showed me that not only was the whole HTML Form wrapped in an UpdatePanel but that the Web Page was actually a Content Page belonging to a Master Page, not a Web Page in its own right. Would that really make a difference ? YES!
Live Worth Living Again
To suppress the full .NET Postback with an AJAX Postback I had to refactor the Web Page so that it was a Content Page and (of course) link it to a Master Page and wrap the whole of the Content in an UpdatePanel. Like so:
asp:Content ID=”Content1″ ContentPlaceHolderID=”ContentPlaceHolder1″ runat=”server”
!– Whole page content is wrapped in an UpdatePanel.
This means all postbacks will be ajax postbacks which means that html extension will
be retained on postback which is what we need for URL Rewriting.
If we permitted a full postback, the postback would be posted to index.aspx and the address bar would
be updated with the aspx URL thus overwriting the pretty html extension. All this occurs because
the form action attribute is set to index.aspx (the real page) even though the URL has been rewritten
to index.html (the pretty URL)–
asp:UpdatePanel runat=”server” ID=”upIndex”
…oodles of Content here…
The corresponding Master Page is but a shell and looks basically like this:
form id=”form1″ runat=”server”
asp:ScriptManager runat=”server” /
asp:contentplaceholder id=”ContentPlaceHolder1″ runat=”server”
I don’t really know why moving all the content to a Content Page should be required to suppress the full postback. But it works for me.