Dear All! I have been using haproxy for more than a year with total satiscation.
This is the first problem we are unable to solve, maybe someone has already meet any similar! There are two JBOSS servers (http, port 8080), behind a haproxy (HA config with keepalived, but this is irrelevant at the moment). Haproxy listens on 80 and 443, port 80 connections are usually redirected to 443. Certs are configured in haproxy. There are browsers using the service without problem. There are also mobile clients (Android and IOS), which also can use the services in most of the cases. The client ocassianoally asks for a URL providing a live video steam. Ther stream is provided in a long single connection, in which the mobile client ask for the live video stream (URL has been recently provided), which is served with sequence of jpeg images. There's a player... blahblahblah The problem is, that currenntly the stream must be provided on a http link, because the https link doesn't work - haproxy responds error 503. We have modified the server to provide http:// links, and added a rule NOT to force the https redirection for the given specific URL path prefix - and it works this way, but we need the video to be passed over a secure channel. The switch: - The same URL which fails from the mobile clients, works with any browser: tested firefox, wget, curl, chrome. Also when running on the very same phone where the client fails. - The mobile client also works with the original https: URLs if not haproxy, but apache/mod-proxy is involved. No other tests performed anyway. - Behaviour is the same on both mobile platforms. - For Android, the same class/member is used to get the URL of the live stream, and to get the stream itself. Forst succeeds, 2nd fails. I guess it should be similar for IOS, but I haven't seen the code yet. Any idea, where to look for the real problem? I have traced the network connection several times. Sometimes the TLS handshake fails for the problematic session (succeds for all other session from the same app using the same code), but not always. haproxy logs <NOSRV> lines for the failed requests, no backend is connected. Like this line here: [09/Oct/2014:11:17:40.832] httpX~ httpX/<NOSRV> -1/-1/-1/-1/642 503 212 - - SC-- 34/3/0/0/0 0/0 "POST /portal/seam/resource/media?stream=1&streamGroupId=10000001&streamId=20b227de-e7d7-4e26-8f92-350657413b5c&deviceId=228 HTTP/1.1" the "same" POST from firefox/rest client: [09/Oct/2014:11:20:16.292] httpX~ backend/server-1 9/0/1/510/75607 200 467801 - - --VN 34/3/3/3/0 0/0 "POST /portal/seam/resource/media?stream=1&streamGroupId=10000001&streamId=20b227de-e7d7-4e26-8f92-350657413b5c&deviceId=228 HTTP/1.1" Regards, Attila
