- From: Thomas Roessler <tlr@w3.org>
- Date: Mon, 23 Feb 2009 22:18:06 +0100
- To: Cullen Jennings <fluffy@cisco.com>
- Cc: Dan Connolly <connolly@w3.org>, www-tag@w3.org
On 23 Feb 2009, at 20:43, Cullen Jennings wrote: > PS. I'm working with linksys folks so you can do something like have > a few NASs in your home behind a full cone NAT. The NAS uses a > service like DynDNS to discover a public port on the NAT and then > uses DynDNS to configure www.mydomain.dyndns.org to point at that > port. Then someone can use a URL like http+srv://www.mydomain.dyndns.org > to reach that web server running on the NAS. This works with > multiple media servers or NASs in the home and allows things like > facebook to reach in and grab that content. It requires no static > port forwarding on the NAT and allowed multiple devices behind the > same NAT to all do this. When the NAS or NAT reboots or get a > different IP address, things all update automatically with no change > to the URL. One way or another, I need to solve this problem and > ship something but I'm very open to what is the best way to solve it. Thinking out loud here, I can see two ways to solve this problem: 1. Use something like SRV records. That's probably the cleanest solution. If SRV lookup gets deployed on clients, then it's likely to work equally well with HTTP and HTTPS. 2. Put a Web server on port 80 of the NAT box that supports name- based virtual hosts and does intelligent things. E.g., forwards transparently depending on the Host header. Or, redirects to another port that then goes straight to the box behind the NAT. This is likely to lead to some trouble with HTTPS (no good), but should otherwise lead to reasonable behavior. Also, is there any reason to believe that http+srv would be easier to deploy in clients than an SRV-aware version of the http URI scheme? (I can't think of any, but I don't claim to have thought through every wrinkle of this proposal.)
Received on Monday, 23 February 2009 21:18:18 UTC