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

good thoughts ... inline ...

On Feb 23, 2009, at 2:18 PM, Thomas Roessler wrote:

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

My worry is that now the user would have to go and configure something  
on the NAT box - basically what domains were in use and what internal  
server they pointed at. This is pretty similar to configuring the  
static port forwarding in NATs. Some technically savvy users manage to  
make it work but trying to explain how to do to most people is very  
hard so I'm trying to avoid that approach.

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

Not really - the main difference seems to be that things that did not  
support the new stuff would not generate an error for http but would  
for http+srv

Received on Monday, 23 February 2009 23:03:26 UTC