The assert on WS_ReserveSize() in ses_handle() can not trip because
sizeof (struct pool_task) is less than sizeof (struct waited). But to safe
guard against future problems if that were to change, this patch makes
sure that the session workspace can hold the largest of them before
entering the waiter, erroring out if not.

Currently, with the 505b7bd9 patch, when
calling WS_ReserveSize with bytes equal to the amount of workspace that is
currently available, it will return zero and mark overflow.

This patch redoes the patch, and changes it to return zero and overflow
only when the requested number of bytes is larger than what is available.

(cherry picked from commit 7da6220d)

Proxy TLVs claiming to have PP2_TYPE_SSL sub-TLVs without complete payload
would cause a Varnish assert. This patch fixes the parsing of the TLVs.

h2_init_sess can only be reached through H1 with either previous knowledge
or opportunistic upgrade. Because of this the proto_priv session attribute
will always be set before entry. This patch simplifies and removes dead
code containing a call to SES_Reserve_proto_priv.

Note: Better diff with the --ignore-all-space option

In h2_init_sess, an extra call was always made to SES_Reseve_proto_priv(),
even though it was already reserved. This wasted a pointer worth of
session workspace. This patch removes the extra call.

If proxy protocol is in use, it is possible to fill the session workspace
exactly before entering http1_new_session(), which will cause it to assert
when calling SES_Reserve_proto_priv().

with this patch we will close the session gracefully.

Ref varnishcache/varnish-cache#3145 / 287dc4a6

(cherry picked from commit d6dec031)

Ref varnishcache/varnish-cache#3145 / 287dc4a6

(cherry picked from commit e1a57eb7)

Patch by @ehocdet, commit message edited by @nigoroll:

The root cause of #3131 was misdiagnosed to the extent that, while this
change had prevented it, the root cause was a bug in WS_ReserveSize()
fixed in 505b7bd9

The previous tlv_string() code was correct except for the
fact that error handling should have checked for WS_ReserveSize(ctx->ws,
len+1) <= len (also spotted by @ehocdet).

Someone had mentioned at some point that we would not want to VRT_fail(),
but I think this must have been related to the proxy transport code, not
the proxy vmod.

Ref varnishcache/varnish-cache#3131

(cherry picked from commit e74f9e87)

Notes:

* for the acceptor, I think it makes sense to keep AN assertion (pun!)
  because varnish is not viable if the session workspace is too small
  to even hold the attributes initialized in the acceptor.

  If this was an issue, we should rather revisit the minimum values for
  the session workspace

* for h1 and h2 session setup, I have used XXXAN() because I am not sure
  how we should best handle allocation failures.

* The relevant bit, for now, is the proxy code which may allocate
  arbitrarily long TLV attributes, so this is the code for which we now
  actually handle errors and test that we do

On the vtc: I added the test to o00005.vtc because there existed a
previous overflow test from 267504b8,
but that only tested for the one case of a WS overflow which was already
handled.

Fixes varnishcache/varnish-cache#3145

(cherry picked from commit 287dc4a6)

(cherry picked from commit 815331b3)

This originates from a3d47c25, but
was overlooked in 4e333597:

When there is insufficient space to fulfil the reservation request, we
must not leave the workspace reserved.

Fixes varnishcache/varnish-cache#3131

(cherry picked from commit 505b7bd9)

(cherry picked from commit ed3b095c)

WS_ReserveSize() does not leave the workspace reserved when the
reservation fails, so WS_Release() must be called for retval > 0 only.

Besides the debug string, it is identical to WS_Reserve() except for

	assert(bytes > 0);

Follow-up varnishcache/varnish-cache#2967

Note: The WS_Reserve() function has not been deprecated as that can
potentially create problems for the build process of VMODs.

(cherry picked from commit 4e333597)

This works with gcc 6.3.0 and clang 3.8.1-24

The test for __GNUC__ is deliberately simple and might not catch all
compilers which would potentially support deprecation marks. While more
specifics could be added, the aim is to raise awareness with developers
and we consider it quite unlikely that anyone does not compile with one
of the main stream compilers at all.

(cherry picked from commit 1594037c)

... to un-confuse the interface

Notes on changes from WS_Reserve():

* Removed the first WS_Assert because all we change is ws->r and we got
  a specific assert on it.

* it follows from PAOK(ws->e) && PAOK(ws->f) in WS_Assert() that
  PAOK(ws->r) && PAOK(b), so we remove the PRNDDN()

Ref: varnishcache/varnish-cache#2967

(cherry picked from commit d001cdd2)

req->err_code and req->err_reason are set when going to synthetic
handling. From there the resp.reason HTTP field is set from
req->err_reason if set, or the generic code based on req->err_code is used
if it was NULL. This patch clears these members so that a value from the
handling of a previous request doesn't linger.

Fixes: VSV00004

Release Varnish 6.2.1

Apply some adjustments to recent patches based off of review by Nils
Goroll at UPLEX (@nigoroll)

When clearing the [CR]LF in a line continuation, we would continue
replacing any [CR|LF|HT|SP] characters up until the end of the buffer,
possibly overwriting later [CR]LFs. Fix this by only unconditionally
overwrite one [CR]LF, and then only replace [HT|SP] with SP to keep with
previous behaviour.

Update r00494.vtc to include multiple line continuations to make sure they
are parsed.

The end of http1_dissect_hdrs ends with skipping over the final [CR]LF
that marks then end of the headers. Currently that skip is optional, that
is, it is skipped if it was present.

This patch adds an assert if the final [CR]LF is not found when finishing
the parsing. HTTP1_Complete guarantees that it is there, if not we would
not have started parsing the request or response in the first place, and
if it is missing, there must be an error in the parsing leading up to it.

In http1_splitline, if the third field is missing, we would still set the
txt.b value to where the field would have been, with a NULL txt.e
entry. This would cause http_Proto to attempt to parse the values
there. Fix this by only setting the .b and .e if the third field was
present.

When parsing a request like this, "GET /\n\n", the first NL would be
overwritten by nul guard inserted after the 2nd field, and the second NL
would be overwritten by the nul guard after the missing 3rd field. This
would cause http1_dissect_hdrs to attempt to decode the body as headers.

The proto field is optional in HTTP, so it may not be set. Set the proto
to 0 also for a NULL value instead of segfaulting if it were NULL.

The macros vct_iscrlf() and vct_skipcrlf() may look at one or two bytes
after its pointer value, causing OOB reads. This would allow
http1_dissect_hdrs to wrongly see a CRLF when one wasn't there (the last
LF left over in the bufer from the previous request).

Change the macros to inline functions, and harden them by always sending
the end pointer so that they can't overflow.

vct_iscrlf() will return an int value of 0 for no [CR]LF, 1 for LF and 2
for CRLF.

vct_skipcrlf() will return the pointer having been skipped 0, 1 or 2
bytes.

This is the first commit in the 6.2 branch, and marks the release
of Varnish Cache 6.2.0.

Happy new year!

This reverts commit de3e581e.

tests/saintmode/test04.vtc from varnish-modules revealed that there may
be use cases where it is implied that vcl_backend_error will leave a
ttl=0 object and the sale object will remain in place.

This can be resolved by:

	- return(abandon) for these cases or
	- making the HSH_Kill conditional on bo->fetch_objcore->ttl > 0

but I already has concerns regarding the impact of this change and have
them even more now.

We need time to ponder about the consequences and a documented
inefficiency is better than unexpected behaviour in a release.

Our stack space canary in v00004.vtc fell off the twig on fedora rawhide
i686

Thank you to @ingvarha for testing, reporting and all your support
overall!

Fixes #2946 in the sense that we want to treat backend synth like any
other object and kill the stale object it replaces.

The two HSH_Kill calls could also be subsumed in vbf_fetch_thread(),
but after an irc discussion, phk decided that he wanted to aim for even
more consolidation later.

The test checks that we remove the stale_oc, but not when abandoning the
bereq.