More IIS oddities

hmmmm.

Script connecting to Oracle database worked fine in MSIE but fails in Firefox and Chrome.

On further investigation we discovered that the problem was due to PHP failing to open the tnsnames.ora file (this tells Oracle clients where on the network and what protocol to use when connecting to the database given in ora_logon / oci_connect).

Let's be quite clear here:
- when the request originated from MSIE, IIS had permissions to open the file
- when the request originated from any other browser, IIS did not have permission to open the file

In both cases, the script executes as the same user on IIS. Using a user-agent switcher on Firefox had no impact.

There is an additional complication that the file in question sat on a network share, but that should have no bearing on how IIS behaves. However using a local copy of the file works as expected.

Micorosft IIS's security model is working differently depending on the browser used - this is potentially a security vulnerability in IIS.

Again, Microsoft IIS is giving different and preferential treatment to MSIE browsers

Microsoft backdoor optimization?

I recently replied to a post on uk.comp.os.linux regarding squid - but on reflection, if the details supplied by the OP are correct, then this exposes some backdoor optimization by Microsoft in IIS

The post and replay are here.

Tim said that:

tim@feynman:~$ telnet www.plumbcenter.co.uk 80
Trying 89.207.160.30...
Connected to www.plumbcenter.co.uk.
Escape character is '^]'.
GET /plumb/index.html HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

HTTP/1.1 400 Bad Request
Date: Wed, 27 Aug 2008 21:44:51 GMT
Server: Microsoft-IIS/6.0
Content-Length: 226
Connection: close
Content-Type: text/html; charset=iso-8859-1
(404 body snipped)

Connection closed by foreign host.

This works if you drop the "; SV1" from the user agent. Or even replace
"; SV1" with "; SV2" or replace "5.1" with "5.0" but leave the "; SV1"
bit!

What's interesting here is that the request headers specify HTTP/1.0 but the response comes back from the server as HTTP/1.1

While maybe this is just sloppy programming by Microsoft, its worth bearing in mind that, by default MSIE degrades to HTTP/1.0 responses when it knows it's talking via a proxy. Also, HTTP/1.1 mainly addresses performance improvements.

Further - as Tim points out, the behaviour of the server changes when the user-agent changes.

Could it be that IIS is using the user-agent for purposes beyond what it should do according to spec? This could give Microsoft an unfair performance advantage over other browsers. Certainly in this case there is hard evidencethat the server is basing its response on the user-agent supplied in the request.

For the time being this is mostly conjecture and conspiracy theory. But it would be interesting to confirm whether IIS always responds to HTTP/1.0 requests with a HTTP/1.1 response, whether it will include HTTP/1.1 specific browser instructions - and to see if the browser then acts on these.