On Fri Jul 22 06:43:45 2011, Willy Tarreau wrote:
Iñaki, what we're saying is that the resolving applies first to HTTP
well before it is WS. For instance, a client could connect to an
HTTP
server, fetch a few objects, then decide to upgrade the connection
to
switch to WebSocket. DNS resolving for WS would not even be involved
here.
I get where you're coming from.
You're saying that you have a nebulous connection thing, that you
pump HTTP requests down, and you may want to use that for WebSocket
upgrade requests as well, by taking the ws URI and performing a
simple transformation on it into an HTTP URI to make the upgrade
request on.
So, given ws://example.com/foo/bar, you'll make the upgrade request
on http://example.com/foo/bar
What Iñaki and I are arguing for is that for WS, there is simply one
additional step prior to finding a suitable connection, which is
performing an SRV lookup/selection.
And this new step can actually be performed before any of the HTTP
connection steps. So, roughly, in order to "do" WebSocket for
ws://example.com/foo/bar you would first do SRV lookup, which would
give you an equivalent HTTP URI to perform the upgrade request. So
for example, if you got:
_ws._tcp.example.com SRV 1 0 ws.example.com
You'd make the upgrade request on the HTTP URI of:
http://ws.example.com/foo/bar
Of course, if this failed to connect, you can find another HTTP URI
to try - something you cannot do without SRV.
Dave.
--
Dave Cridland - mailto:dave@xxxxxxxxxxxx - xmpp:dwd@xxxxxxxxxxxxxxxxx
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf