1

I'm trying to set up a web service, used by our software, on a customer's server. The web service requires .NET 1.1 aspx, etc..., as it was written some time ago and will not be re-written. .NET 1.1 has been installed and the application pool for the web service is set to the .NET 1.1 app pool. Our software uses http post to call the web service (default.aspx page). When doing this, a 403 forbidden is returned. I've created a temporary (html) web page in the server folder that is being accessed by the app. I can successfully browse to the html file without issue. I've looked at various "solutions" on the web to no avail, e.g. granting permissions for the NETWORK_SERVICE and machine accounts, etc... I'm sure it's going to be something embarassingly simple but my head hurts at the moment from banging it against the desk! Anyone seen something similar and resolved it? Anyone got any suggestions of things to try?

Thanks.

SteveC
  • 11
  • 1

1 Answers1

0

Double check at the server level, the ISAPI and CGI Restrictions. Make sure that ASP.NET v1.1 is set to Allowed.

Scott Forsyth
  • 16,449
  • 3
  • 37
  • 56
  • Apologies for the delay in replying. I've had to wait for a remote support session on to the server. ASP.NET v1.1 is allowed in the restrictions. Thanks. – SteveC Mar 21 '11 at 09:27
  • Further things to check are the detailed IIS logs to see what the 403 substatus code is. A 403 error can mean that the default document isn't served too. Also, check event viewer. And, consider creating a new app pool and using that as a test in case something in the app pool framework setting isn't correct. – Scott Forsyth Mar 22 '11 at 14:01
  • Substatus code seems to be 0: #Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken 2011-03-22 15:43:52 W3SVC1 server 200.200.202.118 POST /dwft/default.aspx - 80 - 200.200.202.90 HTTP/1.1 MTE+HTTP+V2.0 - - 200.200.202.118 403 0 0 1463 3190 232 – SteveC Mar 22 '11 at 15:48
  • That's a real forbidden error then. Anything in Event Viewer? Mind you, v1.1 didn't have much in the way of Event Viewer errors. Does v2.0 work? You can try to grant 'everyone' modify permissions to the site path, just in case. That will rule out permissions. It should use your app pool identity that is used, so networkservice should have done the trick. The 'Everyone' is just a double check that something else isn't in play. – Scott Forsyth Mar 22 '11 at 17:31
  • Tried granting everyone access to the site path. Still 403. Can't see anything relevant in any event viewer log. Browsing to pure html files in the folder works OK, just seems to be aspx giving the problem. I've even created a test html page, renamed it as test.aspx and it serves correctly. Thanks for the help so far. – SteveC Mar 23 '11 at 09:18
  • If I understand correctly, it works for a basic .aspx page. In that case, it may not be the .net engine, but it may be something specific within your page. It could be something within your web.config file too. To troubleshoot further, try again creating a simple test.aspx page that simply has "hello world" as the text. If that works then it's not the .net engine, but it's something within your site that is causing the error. Try minimizing your site until you get it working to narrow down the root cause. – Scott Forsyth Mar 23 '11 at 16:56
  • I might have confused things with my last post. I created a basic html page with just a header tag and a success line, then renamed it to have a file extension of aspx instead of htm. – SteveC Mar 24 '11 at 11:45
  • Hi Steve. That's how I understood it. That still suggests to me that a basic aspx page works successfully. I still recommend following the other steps that I suggested to help narrow it down further. – Scott Forsyth Mar 24 '11 at 18:11
  • Hi Scott. Thanks for your help with the investigation with this one. Turns out not to be a problem with either IIS or .NET. The error was being caused because of a mismatch between the schema (.XSD) file on the server and the one expected by our software. Copying the file over from a different, working machine has allowed this to work without errors. – SteveC Apr 11 '11 at 09:02
  • Thanks for the update. Glad you were able to track that down. – Scott Forsyth Apr 11 '11 at 13:14