Protocol Not supported from WinGate

[HCLTIndia]

WinGate is throwing an error: Protocol Not supported. WinGate log shows the following entries:
01/06/06 20:00:44 10.113.23.32 Amitagarwal 0000001122 Requested: version="1.0" encoding="utf-8"?><soap://velope
01/06/06 20:00:44 10.113.23.32 Amitagarwal 0000001122 Error: Protocol not supported - requested version="1.0" encoding="utf-8"?><soap

Anybody has the idea why WinGate restricts this request ?

[Pascal]

I'm assuming this is through the Web Proxy. I'd need to check the source code to see what cases it would log that in (Can only do that Monday), but if you can tell me what client was used to create this situation it would help.

From the look of it the request made was invalid, probably a problem with the client - but can't tell without a bit more information. (A packet capture of that particular session would be very useful)

[HCLTIndia]

I am using a Visual Studio .NET IDE 2003 to run my client application. When the application is run in the IDE, it works fine. But when I double click on the Application's executable, this error gets generated. The client application is a Windows Forms Application. This application connects to a webservice via the WinGate proxy server. The client and the WinGate Proxy server are on the same network but the Webservice is not.
Code that I am using to establish the connection:

//This client uses NTLM authentication
mobjWebService = new WebService();
//10.113.23.96 is the IP of the machine on which the WinGate Proxy
//server is installed.
WebProxy lobjWebProxy = new WebProxy("10.113.23.96", 80);
lobjWebProxy.Credentials = CredentialCache.DefaultCredentials;
mobjWebService.Proxy = lobjWebProxy;
mobjWebService.UserAgent = "Windows";
//Call the method of the WebService
//This method takes 3 parameters: string, DataSet, DataSet[]
mobjWebService.GetFormLibrary(aistrEngine, out aidsPublications, out aidsarrPubListing);



The request header in the WinGate log seems to correspond to that of the SoapRequest sent to the WebService and looks like that WinGate does not recognise this pattern header.

Any clues ??

[Pascal]

Yeah, saw this request come through the Support channel as well. Will work with James on it.

[HCLTIndia]

Yeah, saw this request come through the Support channel as well. Will work with James on it.

[quote="HCLTIndia"]Any updates on this issue Pascal?

[Pascal]

Alright, we seem to have a binary that resolves this issue as well. Our QA team is busy looking through it. Once we have gone through all test cases I'll let you know.

Expect this to be in the 6.1.2 release. (Might send you a binary just to confirm with your application, although I'll test it with that here as well)

[michaelball]

Is this still a problem in 6.2.2?

I have a client who is using our software which is written in Visual Studio .Net 2003 using dotnet 1.1, and connects to our server via a webservice in a very similar way to the example posted in this forum.

If this problem is fixed could you suggest a method for allowing the webservice through the proxy? The user can connect I.E to the service with the proxy settings, but entering the same proxy settings into the software gives a 407 error. This software is distributed to 100+ clients and is working through proxys in other organistations correctly.

(I am a software developer rather than a system administrator and have some knowledge of what a proxy server does, but don't personally have an experience with using proxy servers, so please keep any help in simple terms.)

Cheers for any help

[logan]

The HTTP 407 error stands for "Proxy authentication required", so the problem you are experiencing doesn't sound like the same one in this ticket. Here's a generaly worded explanation of a 407 error.

Your Web server thinks that the HTTP data stream sent from the client (e.g. your Web browser or our CheckUpDown robot) was correct, but access to the URL resource requires the prior use of a proxy server that needs some authentication which has not been provided. This typically means you must log in (enter user ID and password) with the proxy server first.

If the WWW Proxy is requiring users to be authenticated, you should create a new policy in the WWW Proxy server to allow unauthenticated access to the resource your client software is trying to access. I have included the steps to create this new policy below.

- Gatekeeper -> Services tab -> WWW Proxy Server -> Policies
- Click `Add`
- Goto the `Advanced` tab
- Select "Specify which requests..."
- Click `Add Filter`
- Click `Add Criterion`
- Select
- > This criterion is met if
- > HTTP URL
- > contains
- > yoursite.com
- Click OK, OK, then Apply to finalise the change

All users should now have unauthenticated access to yoursite.com.


Alternatively, you could use a different authentication method from the client computer before attempting to make a connection with your software. I suggest trying the QbikAuth tool because it is simple and independant of the WWW Proxy Server. This method will create a bit more user overhead when they want to use your software.

http://www.wingate.com/downloads/QbikAuth.exe

The QbikAuth tool uses the Remote Control Service to authenticate with WinGate, so the RCS must be bound to the adaptor the client is connecting from.