 Kulski, I work for Thetrade. And today I'll be talking about manipulating HTTP headers using full set of substitution formators. But before we start talking about manipulating HTTP headers, let's spend some time talking about access logs. So when Envoy processes transactions and receives a request from downstream client, selects upstream host, transmits the request and waits for the response and eventually sends it back to the client, it produces a lot of data. And the data is extremely valuable when things go wrong. You would like to know what happened? How many times Envoy retransmitted request upstream? How was the time it was waiting for the response? So the easiest way to extract the data is via access logs. So access logs basically a stringer representation of some data which has been produced during those transactions. And it's defined by a sequence of substitution formators. And substitution formator is a string which starts and ends with percentage signed and uniquely identifies the data you would like to display. So here I give an example of a couple of substitution formators, the start time when transaction basically started. The second one is I would like to display a certain header from the request and the response code which was received from an upstream. So now let's move to manipulating HDB headers. So there's a mechanism which has been in Envoy for a while. And basically what it allows you to do is to modify the headers as they pass Envoy on the upstream direction and downstream direction. And so you can manipulate request headers on the response headers. And the way to do it is via configuration. You have to specify two things. One is the name to give to the header to be added. And also you would like to identify the value. So for identifying the value as you see here is we use again the substitution formator. It's a string which starts and ends with a percentage sign and identifies the value which would like to add as a header to that header. It looks exactly like access log substitution formator. So the question is, natural question is, is it the same thing? Are we talking about exactly the same thing? So until now the answer is no. Even though the syntax is exactly the same as we hear for access log and for header manipulation, I can use a substitution formator for hostname, but it has been, it's process is parsed and it's actually converted to a string using completely different code. That's obviously is not super optimal. There is a code duplication to document it into different places, testing effort doubles. So that's from developer point of view. From user perspective things are not much clear because when you look for a specific keyword will be directed into different places. One for access log formators and one for header manipulation. And to make things even more confusing for access logs there is a set of about 80 plus formators and for header manipulation is only about 30 which are available. And so there were questions like, you know, like I cannot use a specific substitution formator for manipulating header, why the same formator is available for access logs? So the answer is because the code was different. There was a different parser and there were different the implementation of the formator itself. So starting with release one 24 things become much more unified. So the same parser is used both for access log the same for header manipulation and the same implementation of the substitution formator. And the substitution formator I mean by substitution formator I mean the code which takes data and converts it into the string. There will be some little bit differences as you see on the for access log and header manipulation for the code and for it as but they mostly limited towards processing the configuration because access logs defined in a different way than header manipulation that code it must be has to be different and testing routines are also different. For the user things become much more easier too because all those substitution formators are defined only in my document that only in one place. And whenever you look for a specific keyword there will be only one result. So you may say, hey, that's great. So whenever I can use the access log formator I can also use it to manipulate the headers but the answer is no. And the difference between why one can be used in access log and one cannot be used into the header manipulator is in timing when data is created. So for access logs, access logs are created when transaction finishes. So and we receive the request from the client selected upstream, sent the request, waited for response and then transmitted to the downstream and then access log is created. And as you see at that moment all the data related to the transactions is already available because the event which happened in the past but that's not true for manipulating the headers. So for example, here I would like to manipulate the request headers, right? But the only data which is available to display at this moment or to use is related to client's connection downstream client connection to Envoy and actually sending the request itself. All the other things like selecting upstream, sending, waiting for response, those are future events they has not happened yet. So using formators which relate to those events doesn't really make sense. And here is an example, right? We try to manipulate the request headers but the format that relates to the event in the future I would like to get some data from response which obviously doesn't happen yet. So in those cases you can still put them but the result will, the result produced by a formator will be empty string. So things are a little bit better when modifying the response headers mostly because it's more data is available. Data related to upstream connection which house has been selected whether the connection was TLS, how many times Envoy tried to reach upstream then the time waited for response all those things are available right now. So here I give an example of upstream request attempt I would like to put into a header how many times Envoy tried to reach upstream. But certain data is still not available. The data which is related to a future event means transmitting response to the client. So here is an example of the byte send. How many bytes are sent back? Envoy sends back to the client. This is his future event and it does not produce the value which we expect. So it's a final thought I would like to present the use case which was not possible to do in prior to release 124. So there is a network of a mesh network of Envoy's and they select next hop based on random algorithm. And I would like this user to know which one has been taken. So in order to do it each Envoy has to be configured with manipulating response headers by adding his own name on top of whatever was received from upstream. And as response progresses from upstream to downstream each Envoy adds its own name. So here when the client eventually gets it it's easy to identify the path. Every time I send it might be a different path. Super easy to debug. All right, that's all. Thank you very much.