IIS Redirect for SOAP

Is their a way of redirecting my SOAP traffic to a different URL using the
IIS redirect feature? I've tried but my soap testing tool just gets the
message "resource has moved to .......".

Re: IIS Redirect for SOAP

Well, if you set up a redirection, the server sends back a 301 or 302
(depending on what kind of redirection you have configured) status code
saying to the client that the resource has moved and can be found in
another place. The client is now supposed to follow the redirection and
make a _new_ request to the new location.

That is how redirection works...it tells the client that the resource has
moved and can be found in another location. So nothing really does seem to
be wrong. Your client does not seem to be able to understand HTTP, hence
it cannot handle this. But the server is doing everything right, you have
told it to send out a redirection, and it does so.

I am not really sure what solution you want for this. If you have no
control over the client, and you know that the client does not understand
HTTP response codes, you will need to develop some kind of server side
redirection so that the client never knows that the resource has moved (so
the old location will always be used by the location, and at this location
you have some kind of code sending a request to the new location and
sending the response to the client). Or you will have to tell all your
clients (the person) that they must use a new URL.

If you can change the client, I suppose that you can make it understand
HTTP and follow a basic redirection.

--
Regards,
Kristofer Gafvert
http://www.gafvert.info/iis/ - IIS Related Info


Paul wrote:

>Is their a way of redirecting my SOAP traffic to a different URL using the
>IIS redirect feature? I've tried but my soap testing tool just gets the
>message "resource has moved to .......".

RE: IIS Redirect for SOAP

Hi Paul,

Just as Kristofer mentioned, the key point is your client's web service
must be able to handle the redirection responses sent from IIS: nothing
complicated, just catch the exception and resend a new request.

I've followed up your thread in BizTalk newsgroup. For your convenience, I
attached the my reply below.

Thanks and have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.


From: wjzhang@online.microsoft.com ("WenJun Zhang[msft]")
Date: Thu, 02 Aug 2007 08:10:49 GMT
Subject: RE: "Side by side" deployment
Newsgroups: microsoft.public.biztalk.general

Hi Paul,

I think this is essentially a web service issue about if redirection works
with normal web service client. It's not directly related to BizTalk.

Based on my knowledge, auto redirection may not work with a Web
Service/SOAP client by simply setting something like
HttpWebClientProtocol.AllowAutoRedirect Property to true. The behavior is
fully based on how the client is implemented.

Either setting up redirection in IIS or redirecting programmatically in
code, the server side sends one of the following HTTP responses to the
client. And the Location header in the response should contain url to the
new resource.

301 - Moved Permanently
302 - Object moved
307 - Temporary redirect

You know that we can use 3 kinds of bindings to call a web service: GET,
POST and SOAP. For GET binding, setting AllowAutoRedirect to true should
work. The proxy class will automatically resend a new GET request per the
url specified in the 30x response's Location header. However for POST and
SOAP bindings(SOAP binding also uses http POST method. The difference is
SOAP XML body part.), the client proxy cannot auto refire the request. This
is because the following definition in RFC 2616:

"If the 301(302/307) status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might change the
conditions under which the request was issued. "

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Since SOAP/POST binding is more commonly used in enterprise application,
what we usually do to handle redirection of web service is writing
additional code on the WS client to catch/handle exception of the 30x
redirection, read the location header in the response and then send a new
request based on the new url.

So in your case, I also think simply setting redirection on the IIS virtual
directory isn't enough. It mainly depends on if the client code has been
written to cover such kind of redirection scenarios.

Below is some discussion that confirms my points:

HowTo detect Automatically a moved WebSevice

*** Problem Description ***
Lets say System A hosts a web service. Then clients A, B, and C, plus some
we don't know about create references to it. Then the web service on System
A moves to System B. Is there any way to have the clients automatically
detect that the web service has moved without recompiling the apps with new
references?

*** Resolution ***
- On WebService client side (proxy) you should set Proxy.AllowAutoRedirect
= true (default = false)
- On Server Side you can return a redirect response with 307 status that
will preserve the method POST (there is no GUI in IIS for that)
(or)
you will have to transfer the body of the request from old location to the
new one using any out of band mechanism (the redirected request will change
on GET method)
(or)
you may use HttpGet Web service protocol for the client (has limited
parameters capabilities)

- Server redirection imposes runtime overhead of two roundtrips one to
server A and another one to server B for every request, which is not good.
- Another way is for the client to query System A for an URL (through a
webmethod) and then use it for subsequent calls.


Hope the information answers the question. And as always, please let me
know if you have any further concern on it.

Thanks and have a nice day.

Sincerely,

WenJun Zhang

Microsoft Online Community Support

==================================================

Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/de fault.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at:

http://msdn.microsoft.com/subscriptions/support/default.aspx .

==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.