Websocket's better support

[jonathan.huot at thomsonreuters.com]

On Thu, Apr 20, 2017 at 17:18 AM,  <dridi at varni.sh> wrote:
> On Thu, Apr 20, 2017 at 9:57 AM,  <jonathan.huot at thomsonreuters.com> wrote:
> > Websocket is (still) not dying, and for us, it seems we have to handle more and more this kind of traffic.
> > It's why I would like to open a discussion and see how we can enhance the websocket support in Varnish.
> >
> > Currently, the implementation is done thru pipe like this :
> >
> > cli (Upgrade) -> recv -> pipe <--> backend
> >
> > So basically, we're putting the ball into backend's hands and nothing else.
> > It has several disadvantages; one of them is that we cannot interact with the handshake's response which is still in HTTP/1.1.
> > E.g. adding a set-cookie for stickiness is not possible.
> > E.g. testing if status code is 101 is not possible
> >
> > So, first problem, first question: do you think it is possible to allow opening the pipe after vcl_backend_response ?
> > The flow will be:
> >
> > cli (Upgrade) -> recv -> pass -> b_fetch -> b_response -> pipe <---> 
> > backend
> 
> It's not, but it's not the first time we discussed it:
> https://github.com/varnishcache/varnish-cache/wiki/VIP8%3A-No-pipe-in-builtin.vcl-in-V5#discussion

Thanks for sharing this Varnish github "wiki", I was not aware of it.
So, if I'm collecting information from VIP6 and VIP8, I can summarize with:

VIP8
13:41 < dridi_> that's because we handle pipe backwards, we should only pipe when there's a 101 switching protocols, after a beresp, not a req 
13:42 < phk> dridi_, relevant point there. 

VIP6 : (..) it's the backend that announces the protocol switch, so getting a transition from vcl_recv to vcl_pipe makes little sense (..) the pipe transition should belong to the vcl_deliver (..)

It looks like we have a consensus to progress into this direction.
I'm working on an implementation for myself but I'm trying to see how it can have benefit for the most.

First, I'm not going to change any behavior of pipe in vcl_recv.
Then, for Websockets, I think the best place to call pipe is in vcl_deliver.
Then, I will relax Varnish to accept 1xx code (those responses are assumed without Body).
Then, either
 we pipe in cnt_transmit after sending back resp to the client, or, 
 we create a new vcl func vcl_deliver_pipe which is the equivalent of vcl_pipe; however I don't see the benefit since we already have access to req/resp in vcl_deliver.

Then, technical questions arise:
- do we update the director API with a new hook http1deliverpipe, or do we update the current http1pipe to be used by both?
- about stats/logs, do we mix them or do we keep them separated?


Do you think it is an doable plan, useful for the overall community? Or do I continue on a fork without trying to make it merge-able ? 

Thanks in advance,
Regards

-- 
Jonathan Huot
Thomson Reuters