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