HTTP request and response egress validation

[walid-git]

This implements HTTP character set validation run on the struct http after vcl_deliver, vcl_synth and vcl_backend_fetch. The idea is to pick up if the VCL program has ended up filling in illegal values that would violate the HTTP protocol.

If a problem is found, we will error out with a 503. If the error is caught in vcl_synth, the connection will be closed.

Authored by: @mbgrydeland @daghf

[nigoroll]

bugwash:

• could/should this be implemented at the transport level?
• but on the other hand, we should probably have the option to go to vcl_synth / vcl_error for error page customization

My personal vote goes to the latter aspect. I think we need to keep the option for customization, even if malformed responses were rightly considered an internal error.

[walid-git]

This PR should probably be discussed again in bugwash regarding error page customization brought up by Nils.

[walid-git]

Bugwash: merge this with the existing FEATURE_BIT(VALIDATE_HEADERS) logic.

[walid-git]

From last bugwash:

<slink> Along these lines, I would think it makes more sense to validate headers "on the way in and upon each change", rather than (again) at agress?

On a second thought, do we really want to make a task fail as soon as an invalid value is written to a header (or any other (be)req/(be)resp field) ? We might have users using headers as temporary variables in VCL and those might contain invalid data, but this should be fine as long as the invalid headers are used internally and removed before the req/resp leaves varnish. That's why I think having a full final check at the very end of VCL processing is a better approach.