Under specific conditions, apicast does not handle correctly the requests with the Expect header. It only happens when the configuration includes a forward proxy configured and upstream listening HTTPS (TLS)

In this scenario (proxy forwarding to tls powered upstream), apicast manages the connection using the lua-resty-http library. Currently, v0.15 is being used.

APIcast call this library and the library fails to parse ONLY when the `HTTP/1.1 100 Continue` continue response has headers. Not very common, but some proxies, like squid, add headers to the "HTTP/1.1 100 Continue" response. The HTTP https://www.rfc-editor.org/rfc/rfc7231 (section 5.2.1 and 6.2.1) specification does not explicitly require or prohibit the inclusion of headers in the 100 response .

Good news: lua-resty-http has already added a fix to that. https://github.com/ledgetech/lua-resty-http/pull/287

Bad news: the fix is on top of some changes that are not backward compatible. When the library is updated, apicast tests start to fail.

The request of this issue is to upgrade lua-resty-http to latest version (as of today v0.17.1) and fix the compatibility issues in apicast. Actually, it simplifies the apicast codebase as it does not longer need to handle the CONNECT upgrade, the new library adds that.

It also would unblock https://issues.redhat.com/browse/THREESCALE-5105 to implement easily mTLS between apicast and the TLS upstream when using Forward proxy

Dev notes: This issue was discovered while integrating APICast with insights project. A patched apicast image was provided https://gitlab.cee.redhat.com/eastizle/apicast-insights with the fix added manually.