views:

194

answers:

2

I have a .net web service that takes some xml data.

From within the web service, I want to manipulate the data and then call a web page that displays information to the user. The web service should return after spaning the web page.

I am not having any luck doing this.

I have tried Server.Transfer(url, end); Which generates the exception since my return has been trashed with the transfer: Client found response content type of 'text/html; charset=utf-8', but expected 'text/xml'.

I have also tried Context.Response.Redirect(url, end); which generate a 302 exception(Object moved).

I have seen various desciptions on how to handle the 302 error. However I dont have control over the client. In this case, my service will be called from a java application so I cant wrap the client side call before making the Web Service call. I need to do it from within the asmx.

// this is very basic but the general gist
[WebMethod]
public string MyRequest(string someXML)
{
    // process the xml, dump do database, invoke aspx page

    string url = "xxxx.aspx";
    bool end = false;

    Server.Transfer(url, end);
    //this.Context.Response.Redirect(url, end);

    return "<retcode>somecode</retcode>";
}

I have looked for examples of this situation or a way to asyncrounously call the web page from within the service and return. Can anyone point me to this pattern or an example?

Thanks

Mike

A: 

You can not do this because because the client is expecting an XML response (the whole point of a web service). You can not force the client to do something completely different from the server side (ie open a completely new application, being the browser).
The client application will need to be changed.

EDIT:
If the web service returns a message that is displayed to the user you could return something like "Please go to [URL] to see the results" and hope the user follows your instructions.

AUSteve
+2  A: 

Unfortunately, if you have no control over the client application, this isn't going to be possible. Think about it from the client app end.

Web services (I'm guessing SOAP in this case) go over http as a convenience, but are really data calls, they are not web pages. As such there is no obligation for the client app to honour a redirect to a website, which is in effect a protocol jump. I'm guessing most SOAP libraries would follow a 302 redirect under the assumption that the data service they are trying to call has moved, so still expecting to find the data service on the new URI.

Assuming also the client is some sort of application (ie, not javascript running in a browser), it probably can't even render a web page, so would have to launch a browser.

If you don't control the client, but do control the protocol / interface, you might be able to define a return type where you expect the clients to launch a browser, but this is basically just asking the client implementors to do what you can't directly.

Andrew M