• Welcome to Tux Reports: Where Penguins Fly. We hope you find the topics varied, interesting, and worthy of your time. Please become a member and join in the discussions.

Show IP address of website in IE8

P

pk

Flightless Bird
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.
 
V

VanguardLH

Flightless Bird
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 <ipname|ipaddr>"
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.
 
R

rob^_^

Flightless Bird
http://www.fiddlertool.com

"VanguardLH" <V@nguard.LH> 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 <ipname|ipaddr>"
> 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.
>
 
P

pk

Flightless Bird
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 <ipname|ipaddr>"
> 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.
 
R

Rob

Flightless Bird
pk <pk@pk.invalid> 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 <ipname|ipaddr>"
>> 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.
 
P

pk

Flightless Bird
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.
 
V

VanguardLH

Flightless Bird
Rob wrote:

> pk <pk@pk.invalid> 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 <ipname|ipaddr>"
>>> 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).
 
V

VanguardLH

Flightless Bird
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.
 
P

pk

Flightless Bird
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.
 
V

VanguardLH

Flightless Bird
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.
 
P

pk

Flightless Bird
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.
 
R

Robert Aldwinckle

Flightless Bird
"pk" <pk@pk.invalid> 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.


---
 
You must log in or register to reply here.
Top