If I attempt to connect to the page using the servername (FQDN or
non-FQDN), the initial GET request from the client IE browser clearly
specify the fully resolved url of the page I want. For example:

GET http://myServer/myPage/Page1 HTTP/1.1

If I attempt the same thing using the server IP address, the initial
GET request from IE does not contain the fully resolved url of the
page. For example,

GET /myPage/Page1 HTTP/1.1

If I repeat these steps using Firefox, I always get the fully resolved
url regardless of using IP or servername.

If I attempt to access a page using the same server as my proxy server,
IE seems to think it isn't going via a proxy. For example:

Proxy server is called 'myProxy' and port is 8080 = myProxy:8080
Target URL is http://myProxy:8080/myPages/Page1

I got the following results from the network trace of the HTTP activity
on my proxy server:

client -> proxy: GET /myPages/Page1 HTTP/1.1
proxy -> client: HTTP/1.1 407 Proxy Authentication Required

As RFC 2616 clearly states that clients must always use absolute URIs
when talking to a proxy server, the initial client request clearly
shows that the client thinks it isn't using a proxy. As a result, when
the server correctly returns the 407 asking for further authentication
(i'm using NTLM), the client discards the request as it doesn't think
it is using a proxy. This results in an access denied error.

If I use the IP-address or FQDN of myProxy, an absolute URI is used in
the initial client request and the NTLM handshake works without
problem.

Basically, if you use either the non-FQDN, FQDN or IP-address for both
the client proxy server and target URI you will experience this
problem. This does not happen with any other browser I have tried.