On Thu, Jul 21, 2011 at 7:47 PM, Bruce Atherton <bruce@xxxxxxxxxxxxx> wrote:
As I understand it, the issue that caused the various drafts for HTTP SRV to die without getting much traction is one of efficiency. It is inefficient to make all these extra DNS calls, especially when it is unlikely that many of the records you are blocking on will exist. Other than the inefficiency, HTTP SRV is just an incremental technology you add to your existing DNS without hurting what already exists. Since Websockets uses the same infrastructure the records are unlikely to exist for it either, so the inefficiency issues are still present.
Hmm, I seem to be arguing myself out of supporting DNS SRV as the preferred location mechanism. That is not the case. I just think that we face some of the same challenges migrating Websockets to SRV as are faced by HTTP because we share the same environment for the most part. Willy's example of a proxy that doesn't know how to resolve host names using the SRV method is a good example. But by advocating for the deployment of SRV records as a best practice for Websockets, we may improve things in the HTTP world as well. It is a shame there is no standard defined for HTTP SRV to point to.
I find myself reminded of my reservations about HTTP Upgrade as the opening handshake. �It is clever, efficient and reflects some of the shared nature between HTTP and WS. � However, I felt it should be considered one of several mechanisms for opening a WS connection, one especially suited for a�co-mingled�environment. � But�not explicitly the only such method. �(I was unable to convince many of my position on that, so I could very well be in the minority about this issue as well) � �I think DNS SRV is in a similar area. � It's a useful technology that if the client uses could be of benefit. � I'm just not convinced there is overwhelming cause to make it a mandatory requirement. � �Saying that nobody will use it if it's not legislated does not strike me as a good enough reason. � The technological advantages are worthy, when it's used, but when it doesn't come into play, there are added inefficiencies. ��Also the name resolution of the HTTP that serves the _javascript_ that opens the WS should remain constant. � If WS resolves the host/domain to a different address than the HTTP it was spawned from, it becomes a method to bypass same-origin / CORS restrictions. � �
I favor a minimalist core with extensibility. � �Name resolution happens before the WS opening handshake, so I continue to see this as outside the domain of the WS protocol. � I would prefer that name resolution be provided by a selectable method. �That way, in 20 years, when name resolution needs have again changed, we'll have the ability to adapt.
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf