Subject: WebSocket ALPN identifier

From: Lucas Pardue <[email-masked]>
Date: Wed, 23 Aug 2017 17:32:50 +0000

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://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>, I have thought about a short I-D similar to draft-ietf-rtcweb-alpn<https://tools.ietf.org/html/draft-ietf-rtcweb-alpn>.

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Aug 2017 17:45:52 +0000

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:[email-masked]]
Sent: Wednesday, August 23, 2017 10:33 AM
To: HTTP Working Group <[email-masked]>
Subject: WebSocket ALPN identifier

Bare with me,

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.

Regards
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 23 Aug 2017 18:10:46 +0000

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 [[email-masked]]
Sent: 23 August 2017 18:45
To: Lucas Pardue; HTTP Working Group
Subject: RE: WebSocket ALPN identifier

Bare with me,

Regards
Lucas

---

From: Mike Bishop <[email-masked]>
Date: Wed, 23 Aug 2017 18:16:49 +0000

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:[email-masked]] 
Sent: Wednesday, August 23, 2017 11:11 AM
To: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: RE: WebSocket ALPN identifier

Hi Mike,

Thanks
Lucas

Bare with me,

Regards
Lucas

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 23 Aug 2017 18:28:20 +0000

Hi Mike,

I'm aware of some of those threads and share a similar opinion to you.

I'm coming at this from a different angle, the WebSocket provides a means to an end for something I'm considering and finding my options limited. To be less vague, delivery of arbitrary protocols to the browser when I don't have access to an API that allows me to create a TCP or UDP socket. See https://bugzilla.mozilla.org/show_bug.cgi?id=1247628

My initial thoight was to coin an identifier that could be reused. However, I think you're suggestion is a good one and I should experiment with some other token.

Thanks 

Lucas
Sent: 23 August 2017 19:16

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]]
Sent: Wednesday, August 23, 2017 11:11 AM
To: Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>
Subject: RE: WebSocket ALPN identifier

Hi Mike,

Thanks
Lucas

Bare with me,

Regards
Lucas