Cookie enable for the second services

[istio]

Cookie enable for the second services

[frankbu]

Istio can't be taking over headers like Cookie, since they belong to the application. Which headers you can use in your routing rules depends on what the application has set at each service call. It's totally up to the application.

That said, maybe there would be some sensible way to allow users to instruct Istio to automatically forward "a copy of" the headers in the ingress request (e.g., "cookie" -> "x-istio-ingress-cookie"). Then you could write rules that match those headers.

I guess this would mean Envoy needs to make a copy of these headers on every incoming request and keep it around for use in every outgoing request ... maybe it's not even possible to keep the threads straight. What do others think about something along those lines?
^^^ @rshriram, @kyessenov, anyone else?

[rshriram]

On Fri, Jul 14, 2017 at 2:21 PM Frank Budinsky ***@***.***> wrote: Istio can't be taking over headers like Cookie, since they belong to the application. Which headers you can use in your routing rules depends on what the application has set at each service call. It's totally up to the application. That said, maybe there would be some sensible way to allow users to instruct Istio to automatically forward "a copy of" the headers in the ingress request (e.g., "cookie" -> "x-istio-ingress-cookie"). Then you could write rules that match those headers. What do others think about something along those lines? ^^^ @rshriram <https://github.com/rshriram>, @kyessenov <https://github.com/kyessenov>, anyone else?

You mean automatically append headers on outbound calls from Envoy? There is a causality issue here at play. We cannot say with 100% certainty that a given outbound call from the app to envoy is related to the most recent inbound call into the app (from envoy)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd1xngMHK8Tdxpaafw1DBfJh-IeCUks5sN7HAgaJpZM4OYZpk> .

-- ~shriram

[TsuyoshiUshio]

Thank you guys for discussing this. :) If this feature is enabled, a lot of project which has a legacy containers with a language-agnostic microservices architecture will be happy. :) Also, I recommend to write on the document that we need to transfer the cookie or some other headers to enable the matcher. If it is a good idea for you guys, I'd happy to contribute via pull request for the documentation.

[rshriram]

On Mon, Jul 17, 2017 at 10:01 AM Tsuyoshi Ushio ***@***.***> wrote: Thank you guys for discussing this. :) If this feature is enabled, a lot of project which has a legacy containers with a language-agnostic microservices architecture will be happy. :)

Which feature are you talking about ? Application has to forward cookie headers to other services if it needs to route requests based on the cookie. From routing rules perspective, cookie is same as any other http header.

Also, I recommend to write on the document that we need to transfer the cookie or some other headers to enable the matcher. If it is a good idea for you guys, I'd happy to contribute via pull request for the documentation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd_D29XyhpUYX0TdxKZ952PrEgjwbks5sO2kmgaJpZM4OYZpk> .

-- ~shriram

[TsuyoshiUshio]

Both is fine for me. :) If we can have a way to use the match routing without revising our legacy code. I don't care about cookie or headers.

[ldemailly]

Just to clarify: without istio your application also doesn't get any frontend user cookies inside web-service (1.0 nor 2.0), right ?

if so what you mean by "without revising our legacy code" ?

[TsuyoshiUshio]

Yes. My current app doesn't have blue green or canary for the web-service. I'd happy to istio help to add functionality to my app to have blue green/canary. However, even if I use the istio, I need to edit my legacy code to transport some cookie. If the istio support the transportation, the istio users who want to have blue green/canary feature, also need to edit their code.

I mean, I have following microservices. A we-front microservice call web-service microservice. In this case, using istio, we can do blue-green for web-front without edit my app. However, If I want to do blue green to the web-service, I need to transfer cookie or other header from web-front to web-service.

Istio, detect the cookie before the web-front, however, before the web-service, the cookie is lost because of the web-front call the web-service. If istio help to transfer the cookie or http headers by configuration, we don't need to edit the current app code.

ingress -> web-front -> web-service

Does it helps?

[ldemailly]

We don't remove cookies, you app has to carry them (like you carry the zipkin, requestid etc... headers) ?

[mumoshu]

Hi @TsuyoshiUshio - I'm trying to understand/explain your idea so that we can move the discussino forward.

Certainly I'm repeating things you might already know but if istio worked like a load balancer or an ingress your explanation would have made sense to me:

Request #1(w/ Cookie X) goes through: browser -...-> L7 ingress/L4 LB -> web-service

However, in your code example, web-front is not something like that. Overall it looks like:

Request #1(w/ Cookie X) goes through: browser -...-> ingress -> web-front
Request #2(w/ Cookie Y) goes through: web-front -> web-service

In this case, making X=Y as you've suggested would be completely up to your application, regardless of the app is legacy or not. And that's why I don't understand what you've said in:

If this feature is enabled, a lot of project which has a legacy containers with a language-agnostic microservices architecture will be happy. :)

For me, it seems like you would have needed to make X=Y if it was really necessary, even in your legacy apps. Then, my question is how actually the requested feature add to your use-case of migrating legacy apps to service-mesh-enabled k8s clusters?

Perhaps your actual use-case doesn't relate with legacy apps at all?
Wouldn't it be something like "I'd like to propagate an user identity in all the sub-transactions across all the microservices originating from a transaction made by the user, only when it is necessary, so that you can extract the identity propagation logic(s) out of microservices written in different languages"?

Then, it sounds like an interesting idea to me but I'm not sure if it should be addressed in istio.

[louiscryan]

This issue is pretty old & stale, closing. Please reopen if you continue to have issues with 0.8 or a newer build.