Re: Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response
|
Martijn de Boer
I assume the reverse proxy functionality between apps would not work when mutual TLS with X.509 certificates is in place. In this case the certificate (forwarded as header) would be filtered out.
Gesendet: Dienstag, 16. Juni 2020 um 09:39 Uhr
Von: "Marco Voelz" <marco.voelz@...> An: "cf-dev@..." <cf-dev@...> Betreff: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response Great, thanks for the clarification!
Warm regards Marco
From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Jonathan is correct.
This issue applies whether or not the reverse proxy is a route service. In fact, while the reproduction steps in the original post used a route service, later in the issue, the original poster indicates that the use case they care about solving for currently is using nginx as the reverse proxy (not as a route service).
And yes, I believe it also applies if the proxy and the backend are deployed on two different CF's (though that is not what we care about now, so if a solution cut that out of scope, I think it'd be fine).
In any case, I think the issue title feels OK still given the above, but thanks for asking the question and giving us a chance to clarify!
From: cf-dev@... <cf-dev@...> on behalf of Jonathan Matthews via lists.cloudfoundry.org <contact+cfdev=jpluscplusm.com@...>
Sent: Tuesday, June 9, 2020 2:37 AM To: cf-dev@... <cf-dev@...> Subject: Re: [cf-dev] Feedback requested: Sticky sessions: If request includes VCAP_ID cookie, always include it in the response
Marco,
I’ve no extra information on this than this thread, but it strikes me that it’s definitely possible to deploy apps to CF which would reverse proxy other apps on CF, *without* attaching them as route services.
I think it might be a interesting and potentially sub-optimal choice to do so, given route services are essentially reverse-proxy-as-a-service(!), but I can definitely see folks doing that. Perhaps with workflows baked in from before route services were a thing.
Overall I’d suggest the framing of this should reference the hosting of both the proxy and the origin service: AIUI both have to be on CF for this thread’s problem and solution to be in scope. They can be *different* CF installations, however, if I’ve got it correct in my head ...
“Reverse proxy applications which are called by a gorouter, and which themselves call a gourouter”? Hmmm. Perhaps a bit too wordy ...
HTH, Jonathan
On Tue, 9 Jun 2020 at 08:47, Marco Voelz <marco.voelz@...> wrote:
-- Jonathan Matthews
|
|
|