Make jsonip.com dual stack IPv4/IPv6 and work for IPv6 addresses too. Return some other useful IP information, such as the PTR, the domain name part of the PTR, and the country code and name.
This brings up something I'm waffling on. Whats the correct content type for JSON?
in your example returning "Content-Type: text/plain; charset=UTF-8" which is nice because FF knows to render it in the browser (good for debugging atleast).
But votes on SO seem to indicate it should be
"application/json"
The correct content-type (MIME type) is indeed "application/json" (edit: downcased JSON, not sure why I made that typo). http://tools.ietf.org/html/rfc4627
Additionally, if no encoding is specified, UTF-8 should be assumed when dealing with JSON.
Some of this is already available elsewhere: I've been using http://ipinfodb.com/ to decide whether to show a region-specific alert on the front page of http://mappin.es
There are two scenarios where such a site has been useful to me:
1) Making sure I deprecated the right addresses in the Linux kernel, and that the kernel was using the outgoing address I wanted instead of the one it would pick via RFC 3484, and
2) Making sure IPv6 browsing is working since turning off v4 is a pain in the ass (in the setups I've had to troubleshoot v6 on, not my home network, where it's much easier).
It's not as easy to parse as JSON, but nor is it very difficult. The format has not changed in years; I've got a regex running I haven't needed to adjust since day 1.
You should probably include the ?callback= functionality anyway. A great deal of libraries assume it will be a get variable, and cater for it specially
your absolutely right, but I did not make jsonip.com
If you are using a framework for this, most of the time you are able to override callback function name, i.e. jQuery uses jsonpCallback : http://api.jquery.com/jQuery.ajax/
If not, load it manually as a script and generate a function for the callback.
Great idea by the way! I don't know what for... yet... but great idea! For some reason I have a strange urge to combine this with http://openkeyval.org/
Finding your own external, visible-to-the-internet IP. You're almost always behind some router these days, so using ifconfig or whatever is pretty useless.
I built some WebSocket code that calls back to the server. I can't hardcode the "server" ip address because I want to deploy it to different places at different times. Sometimes I'm working on my laptop, sometimes its running on Amazon EC2, etc. So, with something like this I am able to build my Javascript so it always knows how to get back to the server.
<yea, I know there are lots of ways to do this, but this is the one I chose. :) sue me. >
Outputting javascript code instead of something parseable (json probably) seems like a very bad idea. Are you really willing to eval code from a site outside your control?
A simple line-by-line regex loop should be enough to parse this though.
Under the same origin policy, a web page served from server1.example.com cannot normally connect to or communicate with a server other than server1.example.com. An exception is the HTML <script> element.
This is perfect. I've been looking for an easy way to find user location (city, state) based on IP address, without having to scrape a IP lookup service for it.
Well, yes - jsonip.com has no AAAA records. I'm not sure that reporting (only! - it only knows where the connection is from) an IPv6 address is all that useful, either.
I'm not in the future yet, but I was under the impression that with IPv6 you would actually know your own public address, because there is no need for NAT. Is this not correct?
NAT will still be possible - just not necessary for conserving address space.
But... imagine trying to get your call-center staff to ask the customer to read back their local IPv6 address so you can troubleshoot. That's going to be bad enough.
Then consider there may be proxies in the way, intentionally or otherwise, so you probably want to know the IP address the customer is hitting your product with, not their computer.
Most of us on HN are probably smart enough to find out our own IPs a half dozen ways - it's the 3rd party support that's tougher.
IPv6 addresses are statically allocated (well, in the IPv6 proponents' designs - in reality, we may end up with DHCPv6 and the like), but almost always provider-allocated (PA), not provider independent (PI); so you'll have to give it back to your ISP when you switch.
This is a good thing, by the way; PI space consumes memory on the backbone routers (they can't just send it to your ISP, after all - the whole point is that you can take it with you). Of course, PA space is just part of a larger allocation to your provider.
I think I'll replace whatsmyip.com for this: alias whatsmyip="curl -s http://jsonip.com | grep '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' -o"
A simple way of accessing your public IP from bash (for some reason I need to do that a lot!)
HTTPS can be proxied, too, transparent or not, and you'll end up with the proxy's IP. (as the HTTP headers are encrypted along with everything else, the proxy can't even include an 'X-Forwarded-For:' header) Still useful for maintaining the full 'lock' icon when embedding in other websites, though including jsonp in an https site somewhat defeats the purpose. You'd need CORS on the server for it to be useful.
An HTTPS proxy can only work when the client explicitly configures it. A proxy that can't cache or modify traffic is more like a NAT router than a proxy.
(I imagine getting the IP of the other side of any NAT router is point of this service.)
You can transparently proxy arbitrary network traffic. See https://github.com/apenwarr/sshuttle for an example. FWIW, I'm only pointing out that HTTPS wins you exactly nothing compared to HTTP for this particular purpose. The concept of the "correct" IP address in the context of NAT and proxies is hazy at best anyway.
Which might be exactly what you want if you are troubleshooting HTTP issues with customers "Go to page X and tell me what it says" rather than "what is your IP" is much more reliable.
If there's a proxy, there's a proxy - but I can't troubleshoot the customer's connectivity issue without that.
Here's the original post with some usage details. http://news.ycombinator.net/item?id=1896015
This is actually running on node.js. If anyone finds a bug or has some suggestions, email me or leave a tweet @geuis.