我正在为ASP.Net 3.5项目开发自定义URL重写器。这个重写器在功能上与大多数重写器没有区别，唯一的区别是友好的URL集合没有从web.config文件加载 - 而是来自数据库。我做了一个天真的假设，从头开始编写自定义重写器模块很容易，但现在我知道我把自己弄得一团糟。我离题了;让我们直接讨论技术问题。
在测试重写器时，我设置了一个友好的URL，将用户带到Web表单。来自此表单的回发不应该像任何人期望的那样改变友好地址，所以
http://my.web.site/app_root/FriendlyURL始终重写为http://my.web.site/app_root/not_friendly/form.aspx
浏览器首次加载FriendlyURL时，情况很好。该页面出现并完全正常运行。但是，当表单回发到服务器时，页面只是重新加载，但在服务器端，IsPostBack为false。就像F5被击中一样，除了确实发生了HTTP POST。
不出所料，当通过“不友好”的URL进行交互时，POST操作会按预期触发回发。这个证据表明HttpContext.RewritePath以某种方式弄乱了页面生命周期，使其失去了对回发操作的感觉。任何指示？感谢。
答案 0 :(得分：3)
感谢StackOverflow，另一个nearly-duplicate problem给了我关于核心问题的提示。简而言之，
设置 PostBackUrl 属性的服务器端组件在回发期间与路径重写系统混乱。或者在路径重写期间，回发系统搞乱了。 （因果关系不明确，但效果就是我在问题中所描述的。）
任何asp：LinkButton，asp：Button或asp：设置 PostBackUrl 的ImageButton（在表单，母版页或用户控件级别）将导致Web表单包含一个__PREVIOUSPAGE隐藏元素，其内容是不透明的，但它在回发期间有一些作用。这是我的问题：有几个asp：LinkButtons设置了PostBackUrl属性。
当页面（表单+母版页+用户控件）没有 PostBackUrl 'd元素时，__PREVIOUSPAGE消失，并且回发混乱消失。因此，在我查看整个站点中的每个asp：LinkButton并将它们转换为普通的<a>元素后，问题就解决了。