Websocket's better support

Dridi Boukelmoune dridi at varni.sh
Tue Apr 25 16:52:42 CEST 2017


> It looks like we have a consensus to progress into this direction.

I wouldn't go as far as saying there's a consensus. If you are
interested in discussing this as a possibility you should attend next
bugwash on IRC (next Monday at 13h if you are in France like I'm
supposing).

I put it on the agenda because of this thread:

https://github.com/varnishcache/varnish-cache/issues/2318

> 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?

You should share your intentions during next bugwash if we manage to
cover that point. I expect this bugwash to be a long one (protip:
lunch at noon).

> 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 ?

I don't reckon doing this on your own would be easy to merge.
Especially for such a breaking change. However it would probably work
better if you took part of the plan from day one. I really have no
idea so join the bugwash instead.

Cheers



More information about the varnish-misc mailing list