RE: WebSocket ALPN identifier

I keep hearing about HTTP over WebSockets from various sources, and I confess I'm still a little mystified as to the problem it's solving.  I'm coming around to the idea that we should define how to support WebSockets over HTTP/2 or HTTP/QUIC, but I'm still not sold on HTTP/WebSockets.

At any rate, if you go there (whether as a redirect or an Alt-Svc), I'd try to avoid the confusion of re-using the ws[s] tokens -- those mean WebSockets, and HTTP/WebSockets would be something new and different.

-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] 
Sent: Wednesday, August 23, 2017 11:11 AM
To: Mike Bishop <Michael.Bishop@microsoft.com>; HTTP Working Group <ietf-http-wg@w3.org>
Subject: RE: WebSocket ALPN identifier

Hi Mike,

When you put it like that, I didn't explain myself too clearly, apologies :)

What I imagine is something more like HTTP-over-WebSockets, with a hand-wavy mapping layer. I realise this sounds strange. 

Deployment would see a client talk to a standard h1.1 or h2 endpoint for request routing. This directs them to a different endpoint that supports WebSockets.

On reflection this could potentially be achieved by rewriting a resource to include ws or wss schemes, or using redirects. However, alt-svc appeared a better fit initially.

Thanks
Lucas
________________________________________
From: Mike Bishop [Michael.Bishop@microsoft.com]
Sent: 23 August 2017 18:45
To: Lucas Pardue; HTTP Working Group
Subject: RE: WebSocket ALPN identifier

My initial reaction is “yes” to both questions.  😊

So the idea is that HTTP clients make a request to an endpoint that might be a WebSocket endpoint, but it instead directs them to make a request elsewhere using HTTP/1.1 which will upgrade to WebSockets?  Why wouldn’t it just Alt-Svc the HTTP resource that the client already expects to support WebSocket upgrades?

Or are you actually talking about HTTP-over-WebSockets?

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Wednesday, August 23, 2017 10:33 AM
To: HTTP Working Group <ietf-http-wg@w3.org>
Subject: WebSocket ALPN identifier

Bare with me,

Imagine a hypothetical system that wants to use Alt-Svc to direct clients to a particular WebSocket endpoint that can deliver appropriately framed HTTP resources.

To support this, I’m thinking of using the ALPN identifier(s) “ws” and “wss”. Since they don’t already exist in the IANA registry<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Ftls-extensiontype-values%2Ftls-extensiontype-values.xhtml%23alpn-protocol-ids&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cbe1ba0347f82410470b908d4ea4d70c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636391065721565917&sdata=DLWk3ZJlcK7ML2yI3lk4IPLVBVwYNsMbYcuTJyuPu%2FU%3D&reserved=0>, I have thought about a short I-D similar to draft-ietf-rtcweb-alpn<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-rtcweb-alpn&data=02%7C01%7CMichael.Bishop%40microsoft.com%7Cbe1ba0347f82410470b908d4ea4d70c0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636391065721565917&sdata=XaQPVL3yX8rFKj7TEJvRiRfOxNHTx2lvKypaTinvsBs%3D&reserved=0>.

I do not intend for the proposed identifiers to be used for actual TLS ALPN during handshake. However, I don’t want to preclude that if there’s a desire to do so.

Is this idea too far in the realm of absurdity? Is HTTPbis the appropriate WG to pursue this in?

Regards
Lucas

Received on Wednesday, 23 August 2017 18:17:14 UTC