Can't explain it in title... see thread..

Wow... where do I begin...

Ok...

here's the scenario"

1) You have an ASP.NET web project.
2) You make a call to a class file inside the project
3) The class file has a function that should read an image from the same web, and return its image data. I use WebClient.DownloadData for this, since I always get security errors with FileStream.

4) You run the project, but get ACCESS DENIED.

5) You find over 2 days of attempts, that IIS seems to squash ip addresses but gracefully allows domain names.

This has been trying me for ages, and I still have no simple solution.

The class needs to map to the image, and all it knows is the image lies inside a folder called Data inside the web (relative url would be /Data/myimg.jpg). So the class needs to be sent a string that dictates the mapped path of the server from which the web is operating, because WebClient doesn't work with relative url's and neither does FileStream.

I assume the class runs under ASPNET account. So I add ASPNET via the IIS tool and give it proper permissions.

Works great.

I deploy the project to a web server which has no domain name, but rather an ipaddress 192.168.1.xxx

Somewhere between IIS and ASP.NET the whole thing breaks down and returns an ACCESS DENIED error.

It appears the two have problems using an ipaddress to grab the image, because if I use the domain name instead, it works.

Anyone else have this problem before?

Sounds like something stupid to me

Things ill check NTFS File Permissions

apart from that i have no idea

Here are some thoughts:
Level 1 (tourist level):
Go into Internet Services Manager and right-click on Default Web Site. Click the [Web Site] tab and make sure that IP Address: is "(All Unassigned)" Also, TCP Port: should usually be 80.

Level 2 (hacker level):
Still problems, see if it's somehow related to the browser:
Pull up a Cmd window and telnet and interract directly with IIS:
telnet <my_ip> 80
type:
GET /my_virtual_directory/my_login.aspx

Make sure GET is uppercase. If it pauses forever, IIS is ignoring your request meaning IIS has the problem, otherwise, if you get a bunch of html printed to the screen, then IIS seems to be working and points to some browser-related issue.

Level 3 (military grade):
Last result, but very powerful: Download and install Analyzer packet sniffer (free). Tell it to watch all packets eminating to/from your browser on port 80. You will be able to see each and every character coming to/from your browser in the order received.

I employed all of these techniques recently. Turns out it was Zone Alarm 5 that I had running that was causing IIS to almost work but caused enough interference to screw up Visual Studio .NET. Once I uninstalled Zone Alarm, everything worked fine, but it still took me two days to figure it out.

cudabean