The 503 synth and 500 minimal response status codes are too misleading
in this context, where the failure is attributed to the client. Among
existing 4XX status codes, this is the closest if we stretch the timeout
definition to "didn't complete rapidly enough before the client went
away".

A VCL failure on the client side transitions to vcl_synth, except
failures from vcl_synth that lead to minimal errors. The ESI transport
is not allowed to reply with minimal responses so this would lead to a
panic.

On top of that, the vcl_req_reset feature flag emulates `return (fail)`
statements when an HTTP/2 client disconnected, resulting in the same
panic scenario.

For sub-requests, we masquerade the fail transition as a deliver and
trade the illegal minimal response for the synthetic response.

Fixes #4022

Adds coverage for tab characters at start/end of field value.

Regarding the "fo o" " bar" header, it cumulates an error in the name
and another in the value, but only one of them will trigger the expected
PROTOCOL_ERROR. Only the invalid "fo o" is checked now, and the other
error is part of the new coverage.
Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Control characters will be caught by vct_ishdrval() anyways, but this
condition would also reject allowed obs-text non-ASCII characters.
Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

Signed-off-by: Dridi Boukelmoune <dridi.boukelmoune@gmail.com>

we can not make the parameter const because API.

(sorry)

as agreed on IRC.

This will allow per-session adjustments and also significantly
lower the risk of inconsistent calculations in the rate limit
code during parameter changes.

Ref #3996

Noticed while porting #3998 to the 6.0 branch with a varnishtest more
sensitive to timing.

With #3998 we need to ensure streams are not going to skip vcl_recv if
reset faster than reaching this step for the request task.

The alternative to prevent the vcl_req_reset feature from interfering
is to simply disable it.

The error check is not performed in a critical section to avoid
contention, at the risk of not seeing the error until the next
transport poll.

Once a client is reportedly gone, processing its VCL task(s) is just a
waste of resources. The execution of client-facing VCL is intercepted
and an artificial return(fail) is returned in that scenario.

Thanks to the introduction of the universal return(fail) proper error
handling and resource tear down is already in place, which makes this
change safe modulus unknown bugs. This adds a circuit breaker anywhere
in the client state machine where there is VCL execution.

A new Reset time stamp is logged to convey when a task does not complete
because the client is gone. This is a good complement to the walk away
feature and its original circuit breaker for the waiting list, but this
has not been integrated yet.

While the request is technically failed, it won't increase the vcl_fail
counter, and a new req_reset counter is incremented. This new behavior
is guarded by a new vcl_req_reset feature flag, enabled by default.

Refs #3835
Refs 61a15cbf
Refs e5efc2c8
Refs ba54dc91
Refs 6f50a00f
Refs b8816994

The goal is for top-level transports to report whether the client is
still present or not.

It was particularly hard to follow once we reach client c3.

Only RST frames received earlier than this duration will be considered
rapid.

This adds parameters h2_rst_allowance and h2_rst_allowance_period,
which govern the rate of which we allow clients to reset h/2 streams.

If the limit is exceeded the connection is closed.

Mitigates: #3996

Refs #3984

Closes #3984

Refs #3984

Refs #3984

Refs #3984

Ref 5df6f8d4