I didn’t have much luck finding out much about this one…
I have an ASP page that is called from code somewhere else with a query string:
[domainpath]/FulfilmentReceipt.aspx?fulfilmentId=226F7486-3D30-439D-92BB-94972234A809
In the Page_Load there’s a Server.Transfer call that should move the response execution to another page with a different query string (the Format() below appears to work fine BTW):
Server.Transfer(String.Format("confirmationReceipt.aspx?bId={0}&f={1}&print=true", basketId, franchiseeId)))
The bit I don’t understand comes next. The transfer call appears to get routed back to FulfilmentReceipt.aspx, the first page, but with the new query string. This then causes an error as the fulfilmentId part of the query string is now missing. Why does this not call into confirmationReceipt as expected?
I can confirm that confirmationReceipt page is never called by debugging into the process and that fulfilmentReceipt is loaded twice. There is no code at all in the Global.asax file so no routing there and the confirmationReceipt page itself has no Redirect or Transfer calls and is pretty simple.
Additionally the error page rendered in the browser’s address bar shows the new query string but as part of the orginal URL. I had thought that the URL seen should not alter as a result of Server.Transfer.
Any ideas?
Many thanks.
UPDATE
I haven’t made any real progress but following Richthofen’s advice gave a result of sorts. Using Response.Redirect instead of Server.Transfer DOES give the desired result when the call is from a browser. But the call is made by a third party library that cannot handle the redirect response.
Trying Server.Transfer with the preserveForm option makes no difference. To clarify, the transfer ends up calling FulfilmentReceipt.aspx?bId={0}&f={1}&print=true. Wrong page, right query string.
MORE UPDATE
I have solved my problem by refactoring the confirmationReceipt page to accept the query string passed to fulfilmentReceipt and changing the Server.Transfer call to simply transfer to confirmationReceipt without specifying a query string. The transfer than goes to the right place with the original query string.
The question still stands though out of curiosity. Is it simply that Server.Transfer cannot deal with urls containing query strings correctly?
As originally posted as an update above I solved my problem by refactoring the confirmationReceipt page to accept the query string passed to fulfilmentReceipt and changing the Server.Transfer call to simply transfer to confirmationReceipt without specifying a query string. The transfer than goes to the right place with the original query string.
It’s not ideal as some of the processing is now done twice (converting the query string into something more useful) but it works so I’m happy.