Hello,
I created a web site, site A, that redirects to another web site, site
B, where a simple web service is hosted. The code to call the web
service is simple.
oWS.AllowAutoRedirect = True
oWS.Credentials = New
System.Net.NetworkCredential("user","pass")
str = oWS.HelloWorld("World")
When I set the URI of the webservice to site B an http trace shows the
following.
POST 401 text/html http://siteB/redirect_test/service.asmx
POST 401 text/html http://siteB/redirect_test/service.asmx
POST 200 text/xml http://siteB/redirect_test/service.asmx
The result of the call
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/
envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance"
xmlns:xsd="http://www.w3.org/2001/
XMLSchema">
<soap:Body>
<HelloWorldResponse xmlns="http://tempuri.org/">
<HelloWorldResult>Hello World</HelloWorldResult>
</HelloWorldResponse>
</soap:Body>
</soap:Envelope>
When I try to test the redirect from site A to site B, I get the
following trace.
POST 301 text/html http://siteA/redirect_test/service.asmx
http://siteB/redirect_test/service.asmx
GET 401 text/html http://siteB/redirect_test/service.asmx
GET 401 text/html http://siteB/redirect_test/service.asmx
GET 200 text/html http://siteB/redirect_test/service.asmx
The result of this call is too long to post and be meaning full, but
the content is the list of methods for the web service. I am sure
most of you are familiar with the html rendering of the .asmx page
that lists the methods.
In both traces you will see 2 lines containing a 401. You can be
assured that security is not an issue. The 401's are a result of the
handshake that takes place to ensure that the user is valid.
The issue appears to be that the initial POST is getting changed to a
GET during the redirect. Thus the post stream that contains my SOAP
envelope is stripped and not sent to the web service at the new site.
If anyone has any ideas on why this may be happening and the best
method for resolving this issue I would greatly appreciate it.
This has been tested using web services hosted on IIS 6.0 and SAP
Netweaver 2004 & SAP ECC 5.0. The calling application was written
using VB.net in Visual Studio 2005. The .net framework version is 2.0
and the useragent string for the calling application is Mozilla/4.0
(compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.42).
If you need any more information about the environment or the calls
being made. Do not hesitate to post them and I will answer them to
the best of my ability.
Best regards.
Tony Clark
Application Developer
Kimball International.
---------------------------------------------------------------------------------------------------------------------------------------------------
Can someone verify that based on the next to last paragraph, automatic
redirects are not possible? However, the last paragraph points to the
fact that redirects are possible but the user agent could process it
incorrectly?
From: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html.
The description for 301 redirects is as follows:
10.3.2 301 Moved Permanently
The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically re-
link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is
cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to the
new URI(s).
If the 301 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.
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.
---------------------------------------------------------------------------------------------------------------------------------------------------
