Forum Discussion
The forward proxy authentication issue is Known Issue ID 451319. Check out this HP forum post:
http://h10025.www1.hp.com/ewfrf/wc/document?docname=c04401463&cc=us&dlc=en&lc=en
Working with F5 the following was reported : This issue has been reported in ID451319 (HTTP CONNECT request with 4xx response with body results in RST) for which a workaround has been provided. The fix should be in a 11.4.1 standard hotfix but I am not sure when the standard hotfix will be available. Since there is a workaround then the choice will be wait for the HotFix or apply the workaround. * Please note that some of the client requests are broken as they don't comply to RFC7231. F5 suspect failure for the clients to connect is due to the malformed host headers. All requests which are HTTP/1.0 are failing while those which are HTTP/1.1 are working. The host headers which are broken do not have a port number at the end. See extract from RFC below. http://tools.ietf.org/html/rfc7231section-4.3.6 4.3.6. CONNECT A client sending a CONNECT request MUST send the authority form of request-target (Section 5.3 of [RFC7230]); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. For example, CONNECT server.example.com:80 HTTP/1.1 Host: server.example.com:80 http://tools.ietf.org/html/rfc7230section-6.3 6.3. Persistence A proxy server MUST NOT maintain a persistent connection with an HTTP/1.0 client (see Section 19.7.1 of [RFC2068] for information and discussion of the problems with the Keep-Alive header field implemented by many HTTP/1.0 clients).
WORKAROUND : While Engineering Services work on the HotFix, to avoid the connections getting reset when clients use the CONNECT method you could apply an iRule to disable HTTP on CONNECT for now: when HTTP_REQUEST { if { [HTTP::method] equals "CONNECT" }{ HTTP::disable } }