[Varnish] #1613: keep-alive is enabled even if req.http.Connection is set to "close"

[Varnish]

#1613: keep-alive is enabled even if req.http.Connection is set to "close"
----------------------+--------------------
 Reporter:  zviratko  |       Owner:
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  4.0.1
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------

Comment (by zviratko):

 Sorry in advance for polluting trac with discussion, but I feel very
 strongly about VCL being blackboxed like this.

 Varnish should either respect the *.http.Connection header at every step,
 or it should use flag like *.use_keepalive to make them independent (to a
 limit!). The latter is more flexible.
 In any way, it must be possible to set it at every step of the workflow,
 because you can not foresee what silly and unexpected things a user will
 do with a things as flexible as VCL (and I consider this a plus!).
 But it should also be transparent and behave in expected way.
 If I set Connection: close at any point, it should be used then next time
 a connection is finished. It should not reset back, it should not
 disregard my changes, it should however respect the response a backend
 sends (and it must allow me to set it back if I want to).
 Maybe I will need to disable keep-alive only for backend connections but
 keep it active for the client - would this even be possible?

 Maybe I will need to have Connection: keep-alive in the response, but
 close the connection in reality (because of proxy chaining, legacy broken
 apps - again, you can not foresee stuff like this).

 Maybe I'll need to use keep-alive for only some cases according to some
 existing VCL logic, most likely implemented in vcl_req and not in
 vcl_deliver.

 Maybe I just want to build crazy non-standard stuff.

 Maybe I just want to be ready for others' non-standard crazy stuff when it
 comes.


 If you want to maintain the level of flexibility that I think we should
 expect, then adding a separate header _and_ exposing how it works in the
 builtin.vcl is the only way to go.

 There might be a technical limitation behind your decision in which case
 this workaround is welcome for now, but it's just not how it should be. I
 love varnish because it is open, contrary to competing blackbox-ish
 solutions, so hiding logic away from me = away from VCL and out of reach
 puts you closer to the propritary crowd.

 It's great that I get calls like this from my former colleagues: "help us
 set up our varnish cache, we know you have the experience and we can pay"

 But when I set up my first production varnish cache years ago, it was
 exactly because I did _not_ need to call a consultant, it was all right
 there in plain sight, open, flexible, standard, yet I could dig into VCL
 and make it do something crazy when needed (and it _was_ needed!).

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1613#comment:2>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator