W3C home > Mailing lists > Public > www-tag@w3.org > February 2009

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

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 24 Feb 2009 00:07:15 +0100
To: Cullen Jennings <fluffy@cisco.com>
Message-Id: <F8BC872A-A349-4432-889F-324D6B2A879B@w3.org>
Cc: Dan Connolly <connolly@w3.org>, www-tag@w3.org
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.

> 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?
Received on Monday, 23 February 2009 23:07:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:00 UTC