Add changelog entry for #1879.

When setting bit n (the n+1th bit) of an n-bit vbitmap, we'd miss to
expand the bitmap and thus overflow our buffer and overwrite the first
bit of the next byte in memory.

(...or something.  Needless to say, somebody with autocrap clue should
stare at this in disbelief.)

  r287541 | dim | 2015-09-07 20:55:14 +0000 (Mon, 07 Sep 2015) | 7 lines

  In libz's inflateMark(), avoid left-shifting a negative integer, which
  is undefined.

  Reviewed by:    delphij
  Differential Revision: https://reviews.freebsd.org/D3344
  MFC after:      3 days

Submitted by:	Pål Hermunn Johansen

Closes #1815

Please note that using underscore in HTTP headers is considered a
really bad idea because many application frameworks map minus to
underscore in environment variables.

Fixes: 	#1768

Conflicts:
	lib/libvcc/vcc_var.c

Fixes #1809, backported from master.

Original patch by Federico G. Schwindt (fgsch) is 54471f2a

Fixes #1815

Refs #1862

Merge from VC master commit ea251504.

There's a recurring pattern throughout the code base of taking over
a reference (by nulling the original) essentially when resources are
freed. Instead of repeating this anti dangling pointers measure, it
can be wrapped in a documenting utility macro.

With this patch we properly handle duplicated headers when using http
conditionals (dubbed backend IMS in Varnish). If the backend first
sends the following:

foo: a
foo: b

the backend forwards these as is. If then the objects grace period
ends, but the object is not evicted from the cached, varnish will send
a if-none-match header to the backend. The backend can then reply with
a status 304 Not Modified. In this case the backend can send new 'foo'
headers, or not. Varnish then has to react accordingly by either
sending the original set of 'foo' headers, or the new set of 'foo'
headers. The attached test checks both cases of backend behavior.

Ref: #1879

Even though the shared memory log should always have only one writer,
the varnish process, this is not enforced by the kernel through access
rights. For this reason, the line

     assert(b->vsc->vcls > 0);

could crash Varnish if a process decided to write to the shared memory
log. Now this bad behavior will just affect other readers of the
shared memory log, and not the varnish process itself.

for response status 204, like 304, set the wantbody flag to false and remove the Content-Length header

try to delete a objhead while it still has a waiting list,
by forcing the last ref holder to rush the WL.

Since the hasher owns the refcounts on objhead, we cannot just
mingle req and objcore refcounts.

Fortunately we don't need to add another refcounter, because all
we really care about is the wl being empty when we drop the last
ref.

The wl/hsh_rush() mechanism will work differently with different
thread-scheduling schenarios, and I cannot definitively rule out
that we can drop the last ref on an oh, while there are still req's
on the waiting list.

Given that, and the existence proof in ticket #1823's race, this
might have been the indicated memory-trampler.

Conflicts:
	bin/varnishd/cache/cache_hash.c

Fixes:	#1823

during VCL load.

All packaging files for 4.0 and 4.1 now live in the
pkg-varnish-cache.git repository.

See https://github.com/varnishcache/pkg-varnish-cache/

This didn't make any sense and should never have been commited.

Allow the backend server to send headers lacking ":"/colon in
them when responding to a conditional request yielding a 304 response.

In master/4.1 such responses are aborted as invalid. The backend is
clearly not feeling well.

Since we've accepted it nicely for 200 responses so far in Varnish 4.0,
continue that trend also for 304s.

Fixes: #1598

Fixes:	#1787

Further investigating into root cause scenarios resulted in the
following insights:

* the bad vxid must have got into vtx->key.vxid by way of
  `vtx_parse_link`

* which is only called for `SLT_Begin` (`vtx_scan_begin()`) and
  `SLT_Link` (`vtx_scan_link()`)

(actually this was known before, but I am now confident that these are
the only cases)

There is no case in the code as of 4.0.3 release where `SLT_Begin` is
emitted with an unmasked vxid, so the issue must be root casue in an
`SLT_Link` link record.

In both cases where unmasked vxids are emitted for `SLT_Link`, the id
comes directly from `VXID_Get()`:

* `cache_fetch.c`

  wid = VXID_Get(&wrk->vxid_pool);
  VSLb(bo->vsl, SLT_Link, "bereq %u retry", wid);

* `cache_req_fsm.c`

  wid = VXID_Get(&wrk->vxid_pool);
  // XXX: ReqEnd + ReqAcct ?
  VSLb_ts_req(req, "Restart", W_TIM_real(wrk));
  VSLb(req->vsl, SLT_Link, "req %u restart", wid);

So unless I have overseen anything significant, the root cause must
have been a vxid spill, which was fixed with
0dd8c0b8 (master) /
171f3ac5 (4.0)

`VXID()` masking would have avoided the issue to surface.

This insight is consistent with two observations:

* the issue only surfaced after `varnishd` running for longer periods
  of time

* the issue didn't go away after a restart of the vsl client, a
  `varnishd` restart was required

This gives confidence that the issue has really been understood
completely and that the root cause has been fixed.

This is an additional safeguard against regressions of #1762

We spilled into the client marker bit when reaching 1<<30

Master commits:
a87b589b
0dd8c0b8

backport of master cfb309ca

Original commit Author: Poul-Henning Kamp <phk@FreeBSD.org>