[Varnish] #1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data

[Varnish]

#1086: VGZ_WrwGunzip loops forever if receiving junk data after end of gzip data
----------------------+---------------------
 Reporter:  martin    |       Owner:  martin
     Type:  defect    |      Status:  new
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  3.0.2
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+---------------------

Comment (by lkarsten):

 Went digging in this a bit today.

 The VGZ_END patch ignores the possibility that there are multiple gzip
 streams concatenated in an object. I wouldn't be surprised if there are
 backends that end up doing this, perhaps after getting a flush() or
 similar. This is speculation, but debugging partial/incomplete responses
 to non-gzip-clients sometime down the road sounds painful.

 I guess the main point is to avoid a spinning thread.

 If we stop after a VGZ_END, we'll get that but may serve incomplete
 objects. We can also make up some magic number of rounds this loop maximum
 should take before aborting, but that isn't very pretty. Another way might
 be to look into the next data chunk after VGZ_END and see if it is a gzip
 header (continue) or not (close connection).

 What is the correct behaviour here?

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