Request handled okay when issued by browser, but not when issued by ASP.NET application on the same machine

Question

I'm debugging two ASP.NET applications running on the same machine under different instances of Cassini and with "custom errors" off. One app is running on port 100 and wants to perform a GET request from the other app running on port 90. So it runs this code:

WebRequest request = WebRequest.Create(
   "http://localhost:90/Controller/Action?Param1=foo&Param2=bar");
request.Timeout = 10000;
request.GetResponse();

and the last line throws a WebException with HTTP 400 code and null InnerException. If I copy the very same URL in clipboard, past it into IE running on the same machine - the request is queued to the app on port 90 and its /Controller/Action/ is invoked and even parameters are passed okay.

What could be the problem origin here and how do I solve it?

HTTP400 is malformed request - try 'http : //localhost:90...', also, what is the inner exception? can you run the requesting app through the debugger? — Jason, Dec 19 '11 at 07:03
@Jason: My fault - the path already had `http://` prefix and the InnerException is null, I updated the question. — sharptooth, Dec 19 '11 at 07:10
Can you test this using IIS rather than Cassini? Ive had issues in the past where behaviour differs between the two. If your app is going to be used in production then I'm guessing you will be using IIS anyway. — WooHoo, Dec 19 '11 at 09:14

score 1 · Answer 1 · answered Dec 19 '11 at 07:12

I think you should try without the params in the url.

WebRequest request = WebRequest.Create("localhost:90/Controller/Action");
request.Timeout = 10000;
request.GetResponse();

if it does work you need to add some user-agent headers to allow the use of params.

Also you should probably look at WebClient. MSDN

personally I would also look at using IISExpress or IIS to develop this kind of solution.

Just an outsider's observation here, consider making this call to the second webmethod via an ajax call from the browser and aggregate the results clientside using javascript (jQuery).

score 1 · Answer 2 · answered Dec 19 '11 at 08:03

1

I would try and use the overload of WebRequest.Create that takes a URI object, that way you can rule out a fat-fingered URL.

answered Dec 19 '11 at 08:03

Jason

15,915
3
48
72

score 0 · Accepted Answer · answered Dec 19 '11 at 09:35

Two hours debugging - and it turned out that service at port 90 would redirect the request back to the service at port 100 but wouldn't provide a required parameter in the URL, so the handler in the service at port 100 would throw an exception and return the HTTP 400 which was then reported by the GetResponse(). The solution was to change the logic so that there's no redirect for this specific request because the redirect would make no sense for this specific request.

And the jury finds both Cassini and ASP.NET to be not guilty.

Request handled okay when issued by browser, but not when issued by ASP.NET application on the same machine

3 Answers3