Revisit URL Rewrite (3): Keep postback address after URL Rewrite

After the URL rewrite, the problem that is often encountered is that the postback destination address in the page is not the address that the client requested, but the address after the URL rewrite. For example, rewrite in one of the previous articles:

<rewriter>
<rewrite url= "^/user/(\d+) $" to= "~/user.aspx?id=$1" processing= "Stop"/>
< Rewrite url= "^/user/(\w+) $" to= "~/user.aspx?name=$1" processing= "Stop"/>
</rewriter>

When the user requests "/USER/JEFFZ", the code appearing on the page is <form action= "/user.aspx?name=jeffz"/>, because when the code is generated, The page uses the current Request.Url.PathAndQuery value to get the action of the form element. This causes the "User.aspx?name=jeffz" to appear in the address bar once postback, which is likely to be a request for the right resources (because it may be rewrite elsewhere, or because of directory-level relationships). In the previous article UpdatePanel and Urlrewrite, I said that you could add a line of JavaScript code at the end of the page to solve this problem:

<script language= "javascript" type= "Text/javascript" >
document.getelementsbytagname ("form") [0].action = window.location;
</script>

The intent of this line of code is so obvious that it modifies the form's action to window.location (the path in the browser's address bar) so that when the page is postback, the destination address will be the address before the URL rewrite. This can make the program work, but it really doesn't make me happy. Why?

Because it's so ugly.

Because we still expose the URL after the rewrite address to the client. As long as users install an HTTP sniffer (such as the famous fiddler), or choose to view the source file directly in IE, our target address is displayed in front of the user without any cover. How can we let users know our rewrite rules? We must solve the problem. The solution is simple and very popular, which is to use control adaptor to change the behavior of the form when it is generated. But what makes me feel strange about this control adaptor is that the vb.net version that was found on the internet was not found in the C # language of Microsoft's main push. Although it's not difficult to rewrite a little vb.net grammar, it's also an extra job. So I'm just going to post this adaptor C # version of the code so that friends can use it directly:

Namespace Sample.Web.UI.Adapters
{public
class Formrewritercontroladapter:
System.Web.UI.Adapters.ControlAdapter
{
protected override void Render (HtmlTextWriter writer)
{
ba Se.　　Render (New Rewriteformhtmltextwriter (writer));
}
public
class Rewriteformhtmltextwriter:htmltextwriter
{public
rewriteformhtmltextwriter ( HtmlTextWriter writer)
: base (writer)
{this
. Innerwriter = writer.　　Innerwriter;
Public
Rewriteformhtmltextwriter (TextWriter writer)
: base (writer)
{this
.　　Innerwriter = writer;
Public
override void WriteAttribute (string name, string value, bool Fencode)
{
if (name = = action)　　)
{
HttpContext context = HttpContext.Current;
if (context. items["Actionalreadywritten"] = = null)
{
value = context.　　Request.rawurl;
Context.　　items["Actionalreadywritten"] = true;
}
base.　　WriteAttribute (name, value, fencode);
}
}