1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Show IP address of website in IE8

Discussion in 'Internet Explorer' started by pk, Feb 24, 2010.

  1. pk

    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.
     
  2. VanguardLH

    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.
     
  3. rob^_^

    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.
    >
     
  4. pk

    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.
     
  5. Rob

    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.
     
  6. pk

    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.
     
  7. VanguardLH

    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).
     
  8. VanguardLH

    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.
     
  9. pk

    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.
     
  10. VanguardLH

    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.
     
  11. pk

    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.
     
  12. Robert Aldwinckle

    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.


    ---
     

Share This Page