Talking to folk trying to implement Fuse custom policy and one thing we could help clarify better is the support for TLS (HTTPS) when implementing a custom policy in Fuse.

We need to explain that HTTP tunneling, i.e. CONNECT verb, is not (intentionally) supported.

We cannot support it, as in that case the traffic would be end-to-end encrypted, and the point of adding the custom policy is to mediate the traffic.

We can and do support exposing the Fuse custom policy via TLS (HTTPS), in order to have the traffic encrypted, but the proxy protocol is HTTP proxy protocol, not HTTP tunneling.

In essence there are at least two HTTPS sessions: client to APICast and then APICast to Fuse custom policy. Most commonly there is a third: Fuse custom policy to the backend service.

For that reason using a HTTP client with configured HTTPS proxy will not be successful, as any/most HTTP clients when connecting through a HTTP proxy towards a HTTPS backend will use HTTP tunnelling (the CONNECT verb).

When connecting to HTTPS backend services via Fuse custom policy proxy APICast will use HTTP proxy protocol, and that's why this issue can be only seen if trying to connect directly to the Fuse custom policy proxy, i.e. bypassing APICast.

Instead of a HTTP client to test the Fuse custom policy proxy one can use netcat, for example:

$ print "GET https://example.com HTTP/1.1\nHost: example.com\nAccept: */*\n\n" | ncat --no-shutdown --ssl camel-proxy 8443

That example connects to camel-proxy host on port 8443 using TLS, indicated by the --ssl parameter of netcat and creates a HTTP proxy request (notice the full URL after the GET verb).

cc stmccart1@redhat.com ecotoper