Show IP address of website in IE8

[pk]

I mean something like Firefox's ShowIP extension, but much simpler, just

seeing the IP the page is coming from.



Is it possible at all? It looks strange to say the least that there are no

ways of doing that.



Thank you.

 

[VanguardLH]

pk wrote:



> I mean something like Firefox's ShowIP extension, but much simpler, just

> seeing the IP the page is coming from.

>

> Is it possible at all? It looks strange to say the least that there are no

> ways of doing that.

>

> Thank you.



Use Fiddler2 to monitor ALL your web traffic regardless of which web browser

you use. You'll get tons of information most of which you won't understand.

After loading Fiddler2 and then visiting a web page, pick a session record

in the left pane of Fiddler2 and then use File -> Properties (or right-click

on the session record and select Properties). The X-HostIP field shows the

IP address of the host from where came THAT content. You really thought web

pages only had one source of content for them?



Also, the web browser doesn't care about the IP address. It doesn't work at

that level. It doesn't establish the socket between your client and the

server host. Your web browser doesn't care about or is involved in the DNS

lookup, if needed, or even in establishing the socket other than requesting

one get created. What Firefox is showing you is outside the realm of its

process. You could've just done the separate "nslookup "

yourself.



http://en.wikipedia.org/wiki/Internet_socket

http://en.wikipedia.org/wiki/Winsock



Your web browser requests the WinSock library to create a socket to the

target host. The socket is all the web browser cares about to communicate

with that host. The web browser (the application or client) requests to

open a socket on your local host and WinSock handles how to get that socket

connected to the destination host. So if you enter an IP name (hostname)

into your web browser, that's really all it knows about. It doesn't really

know the IP address from a DNS lookup that was never part of the web

browser's process to establish a socket.



Just like when you make a telephone call, you only enter the other party's

phone number. You nor your phone don't care about the physical addressing

or routing needed for the connection to find the other party's phone.

Firefox is giving you information that it really doesn't have in its own

session between it and its socket.

 

[rob^_^]

http://www.fiddlertool.com



"VanguardLH" wrote in message

news:hm451b$9ts$1@news.albasani.net...

> pk wrote:

>

>> I mean something like Firefox's ShowIP extension, but much simpler, just

>> seeing the IP the page is coming from.

>>

>> Is it possible at all? It looks strange to say the least that there are

>> no

>> ways of doing that.

>>

>> Thank you.

>

> Use Fiddler2 to monitor ALL your web traffic regardless of which web

> browser

> you use. You'll get tons of information most of which you won't

> understand.

> After loading Fiddler2 and then visiting a web page, pick a session record

> in the left pane of Fiddler2 and then use File -> Properties (or

> right-click

> on the session record and select Properties). The X-HostIP field shows

> the

> IP address of the host from where came THAT content. You really thought

> web

> pages only had one source of content for them?

>

> Also, the web browser doesn't care about the IP address. It doesn't work

> at

> that level. It doesn't establish the socket between your client and the

> server host. Your web browser doesn't care about or is involved in the

> DNS

> lookup, if needed, or even in establishing the socket other than

> requesting

> one get created. What Firefox is showing you is outside the realm of its

> process. You could've just done the separate "nslookup "

> yourself.

>

> http://en.wikipedia.org/wiki/Internet_socket

> http://en.wikipedia.org/wiki/Winsock

>

> Your web browser requests the WinSock library to create a socket to the

> target host. The socket is all the web browser cares about to communicate

> with that host. The web browser (the application or client) requests to

> open a socket on your local host and WinSock handles how to get that

> socket

> connected to the destination host. So if you enter an IP name (hostname)

> into your web browser, that's really all it knows about. It doesn't

> really

> know the IP address from a DNS lookup that was never part of the web

> browser's process to establish a socket.

>

> Just like when you make a telephone call, you only enter the other party's

> phone number. You nor your phone don't care about the physical addressing

> or routing needed for the connection to find the other party's phone.

> Firefox is giving you information that it really doesn't have in its own

> session between it and its socket.

>

 

[pk]

VanguardLH wrote:



> one get created. What Firefox is showing you is outside the realm of its

> process. You could've just done the separate "nslookup "

> yourself.

>

> http://en.wikipedia.org/wiki/Internet_socket

> http://en.wikipedia.org/wiki/Winsock

>

> Your web browser requests the WinSock library to create a socket to the

> target host. The socket is all the web browser cares about to communicate

> with that host. The web browser (the application or client) requests to

> open a socket on your local host and WinSock handles how to get that

> socket connected to the destination host. So if you enter an IP name

> (hostname) into your web browser, that's really all it knows about. It

> doesn't really know the IP address from a DNS lookup that was never part

> of the web browser's process to establish a socket.



Ok thanks. I thought that the process in windows was less opaque.

 

[Rob]

pk wrote:

> VanguardLH wrote:

>

>> one get created. What Firefox is showing you is outside the realm of its

>> process. You could've just done the separate "nslookup "

>> yourself.

>>

>> http://en.wikipedia.org/wiki/Internet_socket

>> http://en.wikipedia.org/wiki/Winsock

>>

>> Your web browser requests the WinSock library to create a socket to the

>> target host. The socket is all the web browser cares about to communicate

>> with that host. The web browser (the application or client) requests to

>> open a socket on your local host and WinSock handles how to get that

>> socket connected to the destination host. So if you enter an IP name

>> (hostname) into your web browser, that's really all it knows about. It

>> doesn't really know the IP address from a DNS lookup that was never part

>> of the web browser's process to establish a socket.

>

> Ok thanks. I thought that the process in windows was less opaque.



It is not correct what VanguardLH wrote.



The winsock library has separate functions for determining the ip address

using a DNS lookup, and connecting to that ip address. There are also

functions for determining the ip addresses associated with a connection.

So it is not at all impossible for a browser to know the ip address

associated with a connection it has set up to a host with a certain name.



If that is a useful thing to know, and if IE8 has a way to access this

information, is a different matter.

Note that there is not something as simple as "the ip address of a website".

A Website, and its pages, normally consist of different elements. Each

of them (e.g. text, pictures, scripts) could come from different servers

on different ip addresses.

 

[pk]

Rob wrote:



>> Ok thanks. I thought that the process in windows was less opaque.

>

> It is not correct what VanguardLH wrote.

>

> The winsock library has separate functions for determining the ip address

> using a DNS lookup, and connecting to that ip address. There are also

> functions for determining the ip addresses associated with a connection.

> So it is not at all impossible for a browser to know the ip address

> associated with a connection it has set up to a host with a certain name.

>

> If that is a useful thing to know, and if IE8 has a way to access this

> information, is a different matter.

> Note that there is not something as simple as "the ip address of a

> website".

> A Website, and its pages, normally consist of different elements. Each

> of them (e.g. text, pictures, scripts) could come from different servers

> on different ip addresses.



Sure, sorry, bad wording on my side. I mean "the IP address to which the

domain name in the address bar URL resolves" (or the one which is picked up

in case it resolves to multiple IP addresses).



The purpose of this is to help troubleshooting a GSLB-balanced website. For

several reasons not relevant here, it would be great if customer support was

able to find out to which of a number of backend servers for the same URL

the user has connected to. Lacking direct support in the browser for this,

the logical next step will be to modify the pages so they expose some

invisible detail that trained people can recognize and which can encode the

location of the server.



Thank you.

 

[VanguardLH]

Rob wrote:



> pk wrote:

>> VanguardLH wrote:

>>

>>> one get created. What Firefox is showing you is outside the realm of its

>>> process. You could've just done the separate "nslookup "

>>> yourself.

>>>

>>> http://en.wikipedia.org/wiki/Internet_socket

>>> http://en.wikipedia.org/wiki/Winsock

>>>

>>> Your web browser requests the WinSock library to create a socket to the

>>> target host. The socket is all the web browser cares about to communicate

>>> with that host. The web browser (the application or client) requests to

>>> open a socket on your local host and WinSock handles how to get that

>>> socket connected to the destination host. So if you enter an IP name

>>> (hostname) into your web browser, that's really all it knows about. It

>>> doesn't really know the IP address from a DNS lookup that was never part

>>> of the web browser's process to establish a socket.

>>

>> Ok thanks. I thought that the process in windows was less opaque.

>

> It is not correct what VanguardLH wrote.

>

> The winsock library has separate functions for determining the ip address

> using a DNS lookup, and connecting to that ip address. There are also

> functions for determining the ip addresses associated with a connection.

> So it is not at all impossible for a browser to know the ip address

> associated with a connection it has set up to a host with a certain name.

>

> If that is a useful thing to know, and if IE8 has a way to access this

> information, is a different matter.

> Note that there is not something as simple as "the ip address of a website".

> A Website, and its pages, normally consist of different elements. Each

> of them (e.g. text, pictures, scripts) could come from different servers

> on different ip addresses.



I guess my point was that the web browser is communication with a socket, an

object defined on the local host. It would need to go beyond that socket to

get information. The functions to which you refer is having the web browser

make API calls to another library to find out information that it doesn't

have for *just* the socket object. It has to use that socket as a reference

to make further inquiries from somewhere else regarding the properties on

the other side of that socket. That other-side information is not needed by

the web browser to use the socket. I'll grant that it may be easier to push

a toolbar button or use a menu to have the web browser request that

additional but unnecessary information although copy-n-paste into a

'nslookup' command isn't much more difficult. I haven't bothered to

investigate what all add-ons are available to IE to provide similar

functionality. There's probably some add-on out there that does this

(beyond my mention of Fiddler which is really a proxy that can get started

by a toolbar button and add-on in IE, but Fiddler is like using an cannon to

swat a fly).

 

[VanguardLH]

pk wrote:



> The purpose of this is to help troubleshooting a GSLB-balanced website. For

> several reasons not relevant here, it would be great if customer support was

> able to find out to which of a number of backend servers for the same URL

> the user has connected to. Lacking direct support in the browser for this,

> the logical next step will be to modify the pages so they expose some

> invisible detail that trained people can recognize and which can encode the

> location of the server.



Does your web farm actually redirect the connection (setup a new socket)

with the backend server to the client (user)? Or will the boundary host

(front-end) still be to what the client connects? Most web farms that I've

seen won't let you drill into their network because they don't want you

mapping their network.

 

[pk]

VanguardLH wrote:



> pk wrote:

>

>> The purpose of this is to help troubleshooting a GSLB-balanced website.

>> For several reasons not relevant here, it would be great if customer

>> support was able to find out to which of a number of backend servers for

>> the same URL the user has connected to. Lacking direct support in the

>> browser for this, the logical next step will be to modify the pages so

>> they expose some invisible detail that trained people can recognize and

>> which can encode the location of the server.

>

> Does your web farm actually redirect the connection (setup a new socket)

> with the backend server to the client (user)? Or will the boundary host

> (front-end) still be to what the client connects? Most web farms that

> I've seen won't let you drill into their network because they don't want

> you mapping their network.



Well, it's GSLB, so there is, say, one server in a US datacenter, one in a

German datacenter, and one in Tokyo. Each has a different public IP, and

they are otherwise undistinguishable (same configuration, serving the same

content). The GSLB box is the authoritative DNS for the domain, and queries

for, say, "server.example.com" are answered with one of the three IPs,

depending on a number of vairiables (geolocation, availability, load and

others). So clients connect directly to the chosen server's public IP.



In a number of cases, for troubleshooting, debug and testing, it would be

extremely useful for customer support to be able to know which server a

customer has connected to, and I thought somehow getting that information

from the browser would be a quick and cheap way to do it (and I also thought

that a browser should make that information available anyway, as it can be

useful in general imho). This is something that should be part of a vanilla

browser install, as customer should not have to install anything extra, so

ideally they should just be told by customer support "please look at this

browser menu and that submenu, and tell me the number you see in the upper

left box" or something like that. That would be great.



But as I said, if that's not possible, then we'll make some almost invisible

tweak in the served pages, so each page encodes some information about its

location. Ideas so far include a white text on white background at the

bottom of the page telling "served by server x" (so that would normally be

invisible, but it could be seen by selecting it with the mouse if you know

it's there), or slightly changing a logo image that appears in the header of

the pages.

 

[VanguardLH]

pk wrote:



> But as I said, if that's not possible, then we'll make some almost invisible

> tweak in the served pages, so each page encodes some information about its

> location. Ideas so far include a white text on white background at the

> bottom of the page telling "served by server x" (so that would normally be

> invisible, but it could be seen by selecting it with the mouse if you know

> it's there), or slightly changing a logo image that appears in the header of

> the pages.



Hidden text can trigger some ad blockers. It sounds like you need to add a

barcode in the page, perhaps next to a graphic so the user wouldn't care

much about it.

 

[pk]

VanguardLH wrote:



> Hidden text can trigger some ad blockers. It sounds like you need to add

> a barcode in the page, perhaps next to a graphic so the user wouldn't care

> much about it.



Thanks for the suggestion.

 

[Robert Aldwinckle]

"pk" wrote in message news:hm5gbb$d4p$1@speranza.aioe.org...





> The purpose of this is to help troubleshooting a GSLB-balanced website.

> For

> several reasons not relevant here, it would be great if customer support

> was

> able to find out to which of a number of backend servers for the same URL

> the user has connected to. Lacking direct support in the browser for this,

> the logical next step will be to modify the pages so they expose some

> invisible detail that trained people can recognize and which can encode

> the

> location of the server.

>

> Thank you.





There's always a cmd window, e.g. to use netstat or ping -n 1. For a

more usable and more functional alternative check out TCPView.





---