Re: http+srv worth its own URI scheme? (ISSUE-49 schemeProtocols-49)

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