Paul has voiced his concerns about the limits of asp.net v2 cross page posting.
I too had the same reaction when I saw what it does and what it doesn't do. The reason that I changed my mind about it, and now I like the way it's done, is that I thought about the problem it sovled, and the problem we think it was supposed to solve.
I'll start off with the problem that we thought it was supposed to solve. Web forms that post to other applications are really doing a kind of web service hack. You send some name/value pairs as parameters to an open port over http, and it returns the result as generally-non-parsable html, to be interpreted by the human sitting at the client browser. It's also kind of analogous to having a button in your windows forms application that opens a new application with some given parameters, maybe using some kind of Process.Start thing. To me, this kind of cross application interaction seems very outdated, and we should be using web services instead. For those of us forced to interact with these systems, I'll present my ideas for how to deal with it in a minute.
Now onto the problem it is intended to solve. Many people making web apps these days are old hands at windows application development. In these environments, when you open a new form, you can still access the objects in the opener form, and use them as parameters and such. This is the development model that Cross Page Posting is designed to support. No more weird things like posting back to the same page, putting items in the Context.Items, and Transfering to the “real” page. You just go to the real page from your button and access the previous page's objects as naturally as you would in a windows application. I think it's great that the asp.net team made this not only possible, but also incredibly easy and intuitive.
So ya, now back to the problem of interfacing with outside applications. I've been giving this some back-burner thought for a while now, and I've come to the same conclusion that the asp.net team has. You don't want to directly post to outside sites from pages that are part of your asp.net web application. Especially not with serverside controls forming the name/value pairs being sent. The base issue, it seems to me, is that the asp.net framework, in exchange for providing you with a server control model, has somewhat taken over the clientside names of the html elements, as well as added a few unseen name/value pairs.
So, maybe what we want is a component that exists for the purpose of being a middleman between our applications controls, and the name/values that the external site is looking for. Maybe this component has a TargetUrl property, and a NameValueCollection which we populate it with the exact names we want, and the server controls provide the values. We then call DoYourThing() on the component, and it does all the neccessary goop to move the user to the url we want.
That hand waving “goop” might do something like this...
If the target is expecting a GET request, we can simply do a Response.Redirect after building the querystring from the NameValueCollection. However, if it needs a POST, which most do, it's gets a bit more complicated. We can have a custom IHttpHandler that generates a regular old form element, with hidden inputs containing the name/value pairs we want. Our component makes a Transfer or Redirect to that handler, with an appropriate querystring built from the NameValueCollection. The handler emits the proper “transitional” form to the client browser, with some script to automatticly submit the form as soon as it is received. Of course, have a submit button for non-script-enabled clients.
I dunno, maybe my solution is a great idea, maybe it's not... but I do think that Cross Page Posting is a great idea and implementation, and that Cross Site Posting with the html generated by Pages and ServerControls is a bad idea.