Re: websockets and limitations of AWS ELB
Krannich, Bernd <bernd.krannich@...>
Same problem statement and solution/workaround here. Changing such a corporate setup usually is much more time consuming (if successful at all) compared to the changes in CF setup as you describe them below.
Products & Innovation Technology
69190 Walldorf Germany
Pflichtangaben/Mandatory Disclosure Statements: http://www.sap.com/company/legal/impressum.epx
Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.
From: Shannon Coen <scoen(a)pivotal.io<mailto:scoen(a)pivotal.io>>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Date: Monday 25 April 2016 at 23:00
To: Cloud Foundry Dev <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] websockets and limitations of AWS ELB
I'm interested to hear from operators how you're supporting websockets for CF on AWS, both for user tailing of app logs from Loggregator, and for apps running on CF that take websocket requests.
Websockets are supported in CF by having a HTTP request containing the Upgrade header reach Gorouter, which will establish a TCP connection to the backend (app instance). Since we need Gorouter to handle the upgrade, your ELB must be configured to listen on a port in TCP mode. However, in TCP mode an ELB wouldn't be able to append the required X-Forwarded-For and X-Forwarded-Proto headers. Assuming you'll keep HTTP over TLS on port 443, you'll need to open an additional port on the ELB for websockets.
To support apps on PWS that take websocket requests, we've added port 4443 to the ELB in TCP mode. In response to feedback that this port is blocked to corporate firewalls, we run a second ELB just for Loggregator, listening on 443 in TCP mode. The domain name for Loggregator's route resolves to this second ELB.
How are you working around this limitation? Do your users have issues with configuring clients to make websocket requests on a non-standard port?
Product Manager, Cloud Foundry