> 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 _______________________________________________ varnish-misc mailing list varnish-misc@varnish-cache.org https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc