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
|
|
|
|
Marco Voelz
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 |
|
|
|
David McClure
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 <contact+cfdev@...>
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:
--
|
|
|
|
Marco Voelz
Dear David,
Thanks for the detailed explanations and the heads-up! While looking at the initial issue in github, I noticed that there's a mismatch in vocabulary between the OP and your team responding: My understanding is this change impacts route service, as they are known to the Cloud Controller, it does not impact any generic setup where people deploy a reverse proxy application and forward from there the requests to individual CF applications. Is this an accurate summary?
In this case, I'd like to see this reflected in the language for the issue/backlog item: only scope this to cf route services, not "cf deployed reverse proxy applications".
In case this influences also reverse proxy applications deployed with other means than route services, I'd need to ping some internal teams to assess the impact of this from their point of view.
Thanks and warm regards Marco
From: <cf-dev@...> on behalf of David McClure <dmcclure@...>
Hi all,
Recently, the following feature request was made for gorouter:
The suggestion for implementing this feature in gorouter is relatively simple and we have validated that it works: If the request includes a VCAP_ID cookie, then always include a VCAP_ID in the response.
While the cookie in the response is redundant in most cases, we think this is a reasonable change to make. It would only impact applications that use sticky sessions.
That said, we wanted to bring this up to a wider audience before proceeding. Please respond here or on the issue if you can share any reasons why we should not make this change.
Additional background:
Currently, when an application sets a cookie that matches one of the sticky session cookie names configured for gorouter, the gorouter will add an additional Set-Cookie header with the name __VCAP_ID__ with the value being the instance ID of the backend that handled that request. On subsequent requests, as the client includes this cookie in the request, the gorouter will route the request to the same instance. If it succeeds, it does not include the instance ID in the response (as this was assumed to be redundant information). The only exceptions currently are 1) if the backend sets the session cookie (most don't do this in every response for the same reason - it's usually redundant), or 2) if the backend instance was not found (e.g. because that instance failed or was rescheduled to another cell).
The current implementation described above works in most cases, but fails in the following way when there is a cf-deployed proxy in front of the backend.
In that case, the request path looks like this:
client -> gorouter -> proxy -> gorouter -> backend
In this scenario, the first gorouter in front of the proxy fails to find the instance ID of the backend, as it only looks for instances of proxy. Because it fails to match, in its response, it sets the cookie to an instance of the proxy app instead, and the subsequent request gets routed to a random backend. It ends up in a pattern where 2 requests go to the same backend at a time, and then flipping to a different one.
A workaround in the current implementation of the gorouter is to always have the backend application set the session cookie. This works, but requires changes to application code.
Thanks!
Engineer on #networking
|
|
|
|
David McClure
Hi all,
Recently, the following feature request was made for gorouter:
The suggestion for implementing this feature in gorouter is relatively simple and we have validated that it works: If the request includes a VCAP_ID cookie, then always include a VCAP_ID in the response.
While the cookie in the response is redundant in most cases, we think this is a reasonable change to make. It would only impact applications that use sticky sessions.
That said, we wanted to bring this up to a wider audience before proceeding. Please respond here or on the issue if you can share any reasons why we should not make this change.
Additional background:
Currently, when an application sets a cookie that matches one of the
sticky session cookie names configured for gorouter, the gorouter will add an additional Set-Cookie header with the name __VCAP_ID__ with the value being the instance ID of the backend that handled that request. On subsequent requests, as the client includes
this cookie in the request, the gorouter will route the request to the same instance. If it succeeds, it does not include the instance ID in the response (as this was assumed to be redundant information). The only exceptions currently are 1) if the backend
sets the session cookie (most don't do this in every response for the same reason - it's usually redundant), or 2) if the backend instance was not found (e.g. because that instance failed or was rescheduled to another cell).
The current implementation described above works in most cases, but fails in the following way when there is a cf-deployed proxy in front of the backend.
In that case, the request path looks like this:
client -> gorouter -> proxy -> gorouter -> backend
In this scenario, the first gorouter in front of the proxy fails to find the instance ID of the backend, as it only looks for instances of proxy. Because it fails to match, in its response, it sets the cookie to an instance of the proxy app instead, and the
subsequent request gets routed to a random backend. It ends up in a pattern where 2 requests go to the same backend at a time, and then flipping to a different one.
A workaround in the current implementation of the gorouter is to always have the backend application set the session cookie. This works, but requires changes to application code.
Thanks!
Dave
Engineer on #networking
|
|
|