Hello Atul,
I do not know the exact behavour of IIS in this matter; but the normal behavour should be that the browser initiates a new request. I think there is some configuration/coding error which forces a relocation or generates false response headers. Relocation will not work since we are dealing with a protocol switch and since the job of the WGate ISAPI is twofold (a filter API and as an extension API which does the actual job) and these parts cannot be manipulated for security reasons.
Since you are switching from http to https you must force the the browser to redirect; there must be an SSL handshaking between browser and server!
There are two ways to do this:
1) The response HTTP-headers must return a 302 with a new Location e.g.:
HTTP/1.1 302 Found
Age 3
Cache Control no-cache
Content-Length 0
Content-Type text/plain; charset=ISO-8859-1
Location https://host/scripts/wgate/.
2) You could use a META tag "refresh" in the HEAD of your (generated) HTML page e.g.:
<head>
<title>redirect to new location</title>
<META HTTP-EQUIV="refresh" content="0;URL=https://host/scripts/wgate/..">
</head>
The first will be faster (no data!), the second has the capability to display a message to the user (for a short time).
I'm not familiar with the ASP scripting but it should not be a problem to manipulate the HTTPheaders (1) or generate the HTML (2) with the postfix of the incoming URL.
Please watch the incoming HTTP headers at your browser to see what the VB Programming API is generating.
Another option might be by manipulating IIS in general; maybe you could redirect the whole http://host/. to https://host/. by using wildcards and redirect variables to get the postfix, see:
http://support.microsoft.com/?id=313074#2
Regards,
Fekke
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.