- From: Cullen Jennings <fluffy@cisco.com>
- Date: Tue, 24 Feb 2009 10:51:02 -0700
- To: Thomas Roessler <tlr@w3.org>
- Cc: Dan Connolly <connolly@w3.org>, www-tag@w3.org
On Feb 23, 2009, at 4:07 PM, Thomas Roessler wrote: > On 24 Feb 2009, at 00:02, Cullen Jennings wrote: > >>> 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. > > So, what's the reason for that configuration to be more complex than > configuring DynDNS for automatic updates? It seems strange to > assume that -- on the one hand -- the user should be able to easily > configure dynDNS to set SRV records, but -- on the other hand -- > assume that the user isn't capable to do an equivalent amount of > configuration on their NAT box. I'm assuming that there would be pretty much automatic stuff for DynDns and the user interface of the box supporting this would know how to do it. The issues is which box you need to do the configuration on, the box receiving the services that benefit from the configuration or some other box which does not. I'm trying to align incentives for the work being done by the box that gets the befit. For example, on your xbox, or you DVD player, you enter a domain name you would like to have at some service such as dyndns, the xbox check dnydns and finds the requested domain is taken but presents you with a list of alternatives, you pick one and it is all done. This is much easier than trying to explain to users how to find and configure their multiple layers of NAT. Many Service providers have a NAT in the DSL modem which the user is not allowed to configure. > > >> 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 > > I'm not sure whether you imply that that's a good thing or a bad > thing. So, my question would then be: What would the user be > supposed to do when http+srv causes some strange error to occur? > Well either way the user current software is not capable of reaching the desired server - but I believe providing an error as early as possible about what the problem is is much better than sending people to the wrong website. Phishing makes the idea of going to the wrong server even more horrifying.
Received on Tuesday, 24 February 2009 17:51:46 UTC