Freigeben über

Change in behavior with Internet Explorer 7 and later in regard to CONNECT requests

  • Artikel

Hi everyone!

 

Well, we’ve come across another behavior that some of you are running into so we thought it was time to do a quick write up on the behavior and why it has changed.  The behavior is a little complicated if you are real savvy with how IE makes connections using the HTTP protocol.  Hopefully, we can give you an overview of the behavior that won’t bore you to tears!

:)

 

Starting with IE7, a behavior change has been made in how IE handles Server certain response codes to web browser connections that originate as a CONNECT request.  Specifically, if a CONNECT request is made by IE to a Web Server and it receives a Server response to that CONNECT request with something other than 200, IE could reject that response as invalid (ERROR_HTTP_INVALID_SERVER_RESPONSE). 

Below is an example of what you might see when connecting to a secure web site with IE using an initial CONNECT with a Proxy Server in between the IE client machine and the Web Server you are connecting to:

 

CONNECT www.MyTestSSLSite.com:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Proxy-Connection: Keep-Alive
Content-Length: 0
Host: www.MyTestSSLSite.com
Pragma: no-cache

HTTP/1.1 200 Connection established
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Via: 1.1 MyTestProxyServer

This is a working example because the Server response to the CONNECT request is a level 200 response code which means the CONNECT request by the IE client has been honored.

Of course, this isn’t the scenario in where IE fails to honor the Server response.  Failure cases we see are when a Proxy Server returns a Server response code other than the expected 200, as seen above.  This can happen for several reasons and is often done purposely by Proxy Server.  The below response, for example, will indeed be rejected by IE is connecting to a Web Server, through a proxy, where a CONNECT request would be used to make the initial secure HTTP connection:

CONNECT www.MyTestSSLSite.com:443 HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Proxy-Connection: Keep-Alive
Content-Length: 0
Host: www.MyTestSSLSite.com
Pragma: no-cache

HTTP/1.1 302 Redirected
Date: Wed, 17 June 2009 14:21:38 GMT
Proxy-Connection: Keep-Alive
Connection: Keep-Alive
Location: https://10.1.0.5/MyTestRedirectPage.html

As you can see in this second example above, the Server response code is now a 302 instead of the 200 expected by IE.  This Server response is telling the IE client to redirect it’s request to a different site than it made the initial CONNECT request to.  Allowing this Server response to be honored by the IE client would be risky because the Proxy Server could return content that IE would interpret as being from the origin server, which Microsoft sees as an unsecure scenario and so honoring the 302 response in this scenario is no longer allowed. This change in behavior doesn’t mean that all Server responses which are not 200 are rejected.  Support for 400-level response codes are still valid and honored in the above scenario.

Please note:   You can see HTTP protocol traffic  using an HTTP tracing tool such as Fiddler or a network analyzer tool such as Microsoft Network Monitor.  Of course the CONNECT request is setting up a secure HTTP connection and so further traffic will be encrypted.  A debug version of wininet.dll can allow you to view encrypted HTTP traffic via the wininet log it can generate.

Well hopefully this blog was more entertaining that fingernail scratches on a chalkboard – until next time!

 

Regards,

The IE Support Team

Comments

  • Anonymous
    February 24, 2010
    It's a nice idea but ! how can we send an error page to the browser when the user is trying to access a site that has been forbidden ?
  • Anonymous
    February 24, 2010
    And No returning 403 do not allow IE 8 to return a clear page stating that the URL is forbidden.