Differences between the client application and the browser in the ASMX web service?

Question

This is a continuation. Selecting a connection string based on the type of request for which I have no answer, and what I thought does not work.

I have a web service that needs to select a specific connection string based on the username that calls it from a browser or from a client application.

I tried:

HttpContext.Current != null? ConnectionStrings["Website"].ConnectionString : ConnectionStrings["Client"].ConnectionString 

but I realized that at some point, even if I use the client application, there is some HttpContext (if someone can explain why it would be great), but the Browser field in Request is "Unknown" . So I tried:

 if ( HttpContext.Current != null ) { if ( HttpContext.Current.Request.Browser != "Unknown" ) { //browser connection string here } else //client app connection string here } else //client app connection string here 

This worked wonders for debugging, but in a test environment, it still points to the connection string with the browser even when called from the client application, as if at some point the browser is not "unknown" ...

Is there an easier / simpler way to do this? The way I do this seems very ugly.

I'm pretty desperate at the moment, as I have no idea why this is happening.

Answer 1

Instead of detecting and enabling a browser type, consider these two suggestions:

Add custom request headers

In your various subscribers, define a new custom header in the Http request.

 HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(url); webRequest.Headers.Add("CallerType", "ClientApp"); // "Browser", etc. 

Then you know exactly what type of client is calling. It would be hard to make a mistake and could not be faked / mistaken.

Include Caller Type in QueryString

 myService.asmx?BrowserType=1 

Add a simple new query parameter for your .asmx web method. This will work the exact same way in a controlled environment, but if other users / developers make mistakes or misrepresent the expected values, you will have to take other measures to correct / process it.

Both allow you to easily define connString for an input value. Perhaps the lack of a modifier / header, you could accept the default value. Your sample question has 2 main results, and the proposed solution will be easily distributed (browser, client application, iPhone, whathaveyou).