Search:
Namespaces
Discussions
.NET v1.1
Feedback
Web Services .ASMX 404 error and VS.NET proxy code url formation
Messages
Related Types
This message was discovered on
ASPFriends.com 'aspngwebservices' list
.
Michael Wells
I'm rather new to web services (this is hour #4), but quickly
encountered a confusing situation regarding VS.NET and a simple web
application call to a crude "Hello World" service. After doing a quick
archive search on this list, I found that several other people have had
similar issues... and I'm hoping that the solution I found will add some
fuel to the investigation.
In my environment, I have a development workstation, a development
server, a test server, a production server, and a proxy server
(Microsoft ISA Server). All systems have internal IP's, except the
production server which -also- has external IP's. That is, each of the
websites on the production server has an internal (10.x) address, and is
also referencable through the ISA Proxy Server using an external
address.
My first attempt to attach to a web service was to build the web
application and the web service as separate VS.NET projects, and to
compile them both to my development server. In this environment, I
received the often-discussed error...
"The request failed with HTTP status 404: Object Not Found."
The error occurred in the VS.NET-generated proxy code for the web
service, so I began examining that for clues. Testing the web service
directly through the ASMX file worked great, as expected, so on a whim,
I decided to publish the web service to production, and then try
accessing it through the external IP (for dicussion, we'll call that
207.100.100.1).
My first observation was that, even though I added the web reference
using the external IP, VS.NET generated the proxy code using the
INTERNAL IP. I'm not even certain how it knew the internal IP (maybe
ISA Server issues a redirection for efficiency?) Testing the web
application again, I found that using the internal IP on my production
server also did not work.
On a whim I decided to try forceably replacing the internal IP with the
external IP in the web service proxy code, I did a search and replace
on the IP's in the DISCO, WSDL, MAP, and CS files (in the web reference
proxy code only), and lo and behold, the calls to the service WORKED.
Questions...
1. Why does VS.NET substitute the internal IP for the external IP when
a Web Reference is created against an external IP (from inside that same
network). Related... how does it determine the internal IP?
2. Why can't an internal application call an internal web service?
These are all valid DHCP-assigned IP addresses... and I've verified that
the web service published to my development server was in fact visible
from that server, so the web application running on that same server
would also be able to see it. Corrollary... why does using the external
IP address to the same web service DLL work?
3. Are other people experiencing this problem also running behind
Microsoft's ISA Proxy Server? Unfortunately I installed ISA yesterday,
and started researching web services today, so I didn't get a chance to
compare against an ISA-less scenario.
Side note: I've noticed that the formation of the proxy code is
inconsistent. For example, in the .MAP file, the url to the DISCO data
is formed using the external IP, while the url to the WSDL data (formed
on the next line of the file) uses the internal IP. =20
Also, Shannon's recommended solution of setting the .Url property
immediately before the call DOES work great (thanks, Shannon), but of
course the underlying code problem is still uncomfortably there. =20
-- Michael Wells
Practical Design Group
Reply to this message...
Alex DeJarnatt
Hi Michael. I'm not sure I can solve your problems, but hopefully I can
give you some information that will help you figure out what's going on.
The URL you see in the proxy comes from the WSDL file, which is
generated by your server. The server picks the URL based on the host
name the client used to make the request for the WSDL doc. So if you get
http://mymachine/foo.asmx
?WSDL the URL in the WSDL (and proxy) will be
http://mymachine/foo.asmx
but if you get
http://1.2.3.4/foo.asmx
?WSDL
(where 1.2.3.4 is the IP address of mymachine) the URL in the WSDL (and
proxy) will be
http://1.2.3.4/foo.asmx
. (You can test this yourself in
your web browser). I have seen behavior before where a proxy server
seems to be changing the IP address to use an internal one when it
forwards the request, but I don't know how to fix that.
For your development problem, verify that the URL in the proxy source
file points to something sensical (you might have to turn on "View all
files").
Hope this helps...
alex
-----Original Message-----
From: Michael Wells [mailto:
Click here to reveal e-mail address
]=20
Sent: Friday, August 16, 2002 10:17 PM
To: aspngwebservices
Subject: [aspngwebservices] Web Services .ASMX 404 error and VS.NET
proxy code url formation
I'm rather new to web services (this is hour #4), but quickly
encountered a confusing situation regarding VS.NET and a simple web
application call to a crude "Hello World" service. After doing a quick
archive search on this list, I found that several other people have had
similar issues... and I'm hoping that the solution I found will add some
fuel to the investigation.
In my environment, I have a development workstation, a development
server, a test server, a production server, and a proxy server
(Microsoft ISA Server). All systems have internal IP's, except the
production server which -also- has external IP's. That is, each of the
websites on the production server has an internal (10.x) address, and is
also referencable through the ISA Proxy Server using an external
address.
My first attempt to attach to a web service was to build the web
application and the web service as separate VS.NET projects, and to
compile them both to my development server. In this environment, I
received the often-discussed error...
"The request failed with HTTP status 404: Object Not Found."
The error occurred in the VS.NET-generated proxy code for the web
service, so I began examining that for clues. Testing the web service
directly through the ASMX file worked great, as expected, so on a whim,
I decided to publish the web service to production, and then try
accessing it through the external IP (for dicussion, we'll call that
207.100.100.1).
My first observation was that, even though I added the web reference
using the external IP, VS.NET generated the proxy code using the
INTERNAL IP. I'm not even certain how it knew the internal IP (maybe
ISA Server issues a redirection for efficiency?) Testing the web
application again, I found that using the internal IP on my production
server also did not work.
On a whim I decided to try forceably replacing the internal IP with the
external IP in the web service proxy code, I did a search and replace
on the IP's in the DISCO, WSDL, MAP, and CS files (in the web reference
proxy code only), and lo and behold, the calls to the service WORKED.
Questions...
1. Why does VS.NET substitute the internal IP for the external IP when
a Web Reference is created against an external IP (from inside that same
network). Related... how does it determine the internal IP?
2. Why can't an internal application call an internal web service?
These are all valid DHCP-assigned IP addresses... and I've verified that
the web service published to my development server was in fact visible
from that server, so the web application running on that same server
would also be able to see it. Corrollary... why does using the external
IP address to the same web service DLL work?
3. Are other people experiencing this problem also running behind
Microsoft's ISA Proxy Server? Unfortunately I installed ISA yesterday,
and started researching web services today, so I didn't get a chance to
compare against an ISA-less scenario.
Side note: I've noticed that the formation of the proxy code is
inconsistent. For example, in the .MAP file, the url to the DISCO data
is formed using the external IP, while the url to the WSDL data (formed
on the next line of the file) uses the internal IP. =20
Also, Shannon's recommended solution of setting the .Url property
immediately before the call DOES work great (thanks, Shannon), but of
course the underlying code problem is still uncomfortably there. =20
-- Michael Wells
Practical Design Group
| [aspngwebservices] member
Click here to reveal e-mail address
=3D YOUR ID
|
http://www.asplists.com/asplists/aspngwebservices.asp
=3D JOIN/QUIT
|
http://www.asplists.com/search
=3D SEARCH Archives
Reply to this message...
Michael Wells
I've confirmed that ISA cased the url-mangling problem. After telling
Microsoft ISA server to "Send the original host header...", I can create
Web References without the IP addresses being changed.
However, regarding the inability to access web services inside my
network, I'm still unenlightened. Here are some more details that might
help...
+ I'm designing several websites that have similar business logic; so
I'm factoring that logic out as web services. In this design, each
website has its own IP address (10.0.0.1, 10.0.0.2, ...), and the web
service has a separate IP address (10.100.0.1).
+ I've verified that the URL in the VS.NET-generated proxy code is
correct, in all files. I've also tried overriding the URL immediately
before the call, using the .Url property.
+ I've verified that the published web service is accessible at it's IP
address (10.100.0.1), both from the development workstation and from the
development server where it resides.
+ All of these websites and the web services happen to be running on
the same physical server, which has multiple IPs assigned. This
configuration has been replicated for the development, test, and
production servers. =20
+ I've done a direct file comparison between the two versions of the
VS.NET proxy classes (all 4 files: DISCO, WSDL, CS, and MAP). The only
difference between the internal and external versions of the proxy are
the IP addresses. Everything else is 100% identical.
I would much appreciate any recommendations/solutions anyone has; it's
somewhat of a problem to have to publish the web service to production,
in order to access it from development. Thanks!
-- Michael Wells
Practical Design Group
[Original message clipped]
Reply to this message...
Michael Wells
Thanks Alex, your comments helped tremendously. I think I understand
the proxy code-formation mechanics a little better now. Please check my
thinking...=20
1. The WSDL file is generated by the webservice for each caller that
wants to attach to the web service. This file is stored on the client,
and is used by its tools/compilers to describe the attachment. Like an
IDL file used in DCOM.
2. At the point the WSDL file is generated, the web service uses the
URL information that exists in the HTTP request (including the host
header).
3. VS.NET uses the web service's built-in WSDL generator to get the
attachment details, stores a copy locally, and then generates some class
wrappers for programmatic access.
If my understanding is correct on these items, then I suspect that the
ISA Proxy is the culprit for the hostname change. By default, ISA
replaces the hostname on IP packets destined for a "published
webserver". So while VS.NET is requesting
http://207.100.100.1/foo.asmx?WSDL
, the web service is seeing
http://10.0.0.1/foo.asmx?WSDL
. I can probably fix this formation
problem by forcing ISA to pass the original header through unmodified.
(I will check this afternoon)
Assuming all of this is right on-the-money, this might be a small
security hole, in that anyone who accesses a web service ?WSDL through
Microsoft's ISA Proxy can see the internal IP of that webserver.
Assuming HTTP-header formation is left at ISA defaults. Is there a way
to force the web service to report the correct external IP by specifying
it manually, so that we don't have to worry about deployment scenarios?
This probably explains the hostname change... but why can't the client
access the web service internally? It seems that this should be a
trivial task, since it's just an HTTP request.
-- Michael Wells
Practical Design Group
[Original message clipped]
Reply to this message...
Alex DeJarnatt
Michael, I'm glad you were able to figure out how to get ISA to do this.
I'm going to save your email since I'll probably hear about this again.
;)
The problem in your internal network probably has to do with your proxy
setup. I assume you've tried pinging the server to make sure you have
basic IP functionality. Web service clients use
System.Net.
HttpWebRequest
to make the HTTP request to the web service.
By default
HttpWebRequest
uses the built-in system proxy settings for
the user, so it's possible your client is trying to go through a proxy
server to the outside network to get to a local address. I'm not sure
how to change those for the asp.net user, but you can give
HttpWebRequest
settings directly in config. Look in machine.config for a
template (look for <defaultProxy> under <system.net>).
There's no way to change the host name in the generated WSDL and DISCO
files. In the past we've recommended that people turn off
auto-generation of these files (instructions at the end of my mail) to
save server processing time and instead point people to static versions
of the files. So to be sure of the host name you're giving users you can
edit the files directly.
Alex
Here's how to turn off WSDL and DISCO generation (this also turns off
the "help page"/test form.
In web.config:
<configuration>
<system.web>
<webServices>
<protocols>
<remove name=3D"Documentation"/>
</protocols>
</webServices>
</system.web>
</configuration>
-----Original Message-----
From: Michael Wells [mailto:
Click here to reveal e-mail address
]=20
Sent: Saturday, August 17, 2002 11:38 AM
To: aspngwebservices
Subject: [aspngwebservices] RE: Web Services .ASMX 404 error and VS.NET
proxy code url formation
I've confirmed that ISA cased the url-mangling problem. After telling
Microsoft ISA server to "Send the original host header...", I can create
Web References without the IP addresses being changed.
However, regarding the inability to access web services inside my
network, I'm still unenlightened. Here are some more details that might
help...
+ I'm designing several websites that have similar business logic; so
I'm factoring that logic out as web services. In this design, each
website has its own IP address (10.0.0.1, 10.0.0.2, ...), and the web
service has a separate IP address (10.100.0.1).
+ I've verified that the URL in the VS.NET-generated proxy code is
correct, in all files. I've also tried overriding the URL immediately
before the call, using the .Url property.
+ I've verified that the published web service is accessible at it's IP
address (10.100.0.1), both from the development workstation and from the
development server where it resides.
+ All of these websites and the web services happen to be running on
the same physical server, which has multiple IPs assigned. This
configuration has been replicated for the development, test, and
production servers. =20
+ I've done a direct file comparison between the two versions of the
VS.NET proxy classes (all 4 files: DISCO, WSDL, CS, and MAP). The only
difference between the internal and external versions of the proxy are
the IP addresses. Everything else is 100% identical.
I would much appreciate any recommendations/solutions anyone has; it's
somewhat of a problem to have to publish the web service to production,
in order to access it from development. Thanks!
-- Michael Wells
Practical Design Group
[Original message clipped]
| [aspngwebservices] member
Click here to reveal e-mail address
=3D YOUR ID
|
http://www.asplists.com/asplists/aspngwebservices.asp
=3D JOIN/QUIT
|
http://www.asplists.com/search
=3D SEARCH Archives
Reply to this message...
System.Net.HttpWebRequest
Ad
MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT
Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
Contact Us
-
Terms of Use
-
Privacy Policy
-
www.dotnet247.com
