WEBVTT NOTE Created by CaptionSync from Automatic Sync Technologies www.automaticsync.com 00:00:00.196 --> 00:00:08.416 align:middle Aright! Welcome to my talk on Varnish. 00:00:09.696 --> 00:00:18.606 align:middle Today I want to talk about how to use Varnish, not just for caching static information kind 00:00:18.606 --> 00:00:24.676 align:middle of things that are the same for everybody, but caching when the content 00:00:24.676 --> 00:00:28.866 align:middle that you show depends somehow on who is viewing that content. 00:00:29.436 --> 00:00:36.126 align:middle If you've heard some caching in general, I really like this quote 00:00:36.206 --> 00:00:40.386 align:middle to explain why do we do the kind of HTTP caching, 00:00:40.386 --> 00:00:42.926 align:middle like the caching where we cache the whole page. 00:00:43.616 --> 00:00:50.556 align:middle In the end, like all that we do, if you do a visual website or if you do an API, 00:00:50.656 --> 00:00:55.106 align:middle the output is some kind of text content and if somebody else, 00:00:55.926 --> 00:00:58.036 align:middle it's exactly the same text content. 00:00:59.366 --> 00:01:05.046 align:middle The HTTP cache is the most efficient because you'll see, okay: he's asking for, 00:01:05.086 --> 00:01:09.296 align:middle he's asking the same question, he gets the same answer and that's really, really easy. 00:01:09.396 --> 00:01:22.956 align:middle You don't even have to touch your actual web server Sometimes people start looking at caching 00:01:22.956 --> 00:01:29.626 align:middle because they realized, "Oh our page is slow, so if we have a cache, it's going to be fast." 00:01:30.356 --> 00:01:36.166 align:middle It's not exactly right or it's a bit... 00:01:36.646 --> 00:01:40.536 align:middle like the main reason why you want to do caching is to allow scaling 00:01:41.306 --> 00:01:47.836 align:middle because you will always have cache misses: like moments when the cache doesn't know the response 00:01:47.836 --> 00:01:54.166 align:middle and you have to hit the application and if the application takes five seconds to render a page, 00:01:54.766 --> 00:01:57.446 align:middle some of your users will have a shitty experience. 00:01:57.826 --> 00:02:00.366 align:middle Cache can't fix that problem. 00:02:00.366 --> 00:02:01.966 align:middle It will have... 00:02:02.436 --> 00:02:06.836 align:middle it will lower the number of people that have a bad experience 00:02:07.306 --> 00:02:09.666 align:middle but it won't make the bad experience go away. 00:02:10.656 --> 00:02:18.206 align:middle So the actual like the good motivation for caching is 00:02:18.206 --> 00:02:24.606 align:middle to say we: we want to be able to scale. 00:02:24.606 --> 00:02:30.026 align:middle We want to scale with less servers because if there is many people asking for the same thing, 00:02:30.626 --> 00:02:32.896 align:middle it doesn't take us a lot of resources. 00:02:34.046 --> 00:02:39.476 align:middle But the application behind should still be in a reasonable shape to deliver pages. 00:02:41.946 --> 00:02:49.186 align:middle Now varnish or any kind of caching proxy on that level, they don't know about the application. 00:02:49.186 --> 00:02:55.136 align:middle They know about HTTP, about the transfer of the data and they see it as a proxy 00:02:55.636 --> 00:03:00.246 align:middle between the Internet and your actual web application. 00:03:00.996 --> 00:03:03.776 align:middle So you have the requests coming through the proxy. 00:03:04.036 --> 00:03:06.136 align:middle It checks, "oh do I have that in my cache?" 00:03:06.376 --> 00:03:11.816 align:middle If it doesn't, it goes to the backend, gets the response. 00:03:12.156 --> 00:03:20.396 align:middle And if the response is cacheable, if it, if it is, um, there is ways for the server to tell: 00:03:20.396 --> 00:03:24.166 align:middle "Hey you can cache this response" or "Hey you shouldn't cache that". 00:03:24.636 --> 00:03:29.906 align:middle If it's cacheable it will store it at that point and then return the response. 00:03:30.546 --> 00:03:33.956 align:middle And then the next time somebody asks for the same thing, it will see: 00:03:33.956 --> 00:03:36.986 align:middle "oh I have it in the cache" and immediately return. 00:03:37.616 --> 00:03:42.546 align:middle And with varnish that's like a single digit millisecond time that it needs to, 00:03:43.726 --> 00:03:48.126 align:middle to handle a cache hit, that's like really, really fast and it doesn't take much resources. 00:03:48.126 --> 00:04:00.516 align:middle Real World Caching: User-Specific Data So the easy case of caching is when you have some kind 00:04:00.516 --> 00:04:05.606 align:middle of page that is the same for everybody that's really easy. 00:04:05.776 --> 00:04:16.126 align:middle But in real world for example, let's look at this newspaper thing which has here, 00:04:16.126 --> 00:04:20.566 align:middle there is the weather, it is localized, it's talking about Zurich. 00:04:20.566 --> 00:04:23.776 align:middle Maybe if you come from Berlin it will show you the Berlin weather. 00:04:26.206 --> 00:04:31.816 align:middle There is something related to your session, like here you can log in and I assume if you logged 00:04:31.866 --> 00:04:34.136 align:middle in it would show your name, stuff like that. 00:04:35.526 --> 00:04:42.186 align:middle So this depends on, on if you're logged in, this depends on where you access the page from 00:04:43.516 --> 00:04:49.776 align:middle and then there is some kind of things that are updated repeatedly. 00:04:49.776 --> 00:04:54.116 align:middle Like all the time they edit and update this and then there is some kind 00:04:54.116 --> 00:04:56.326 align:middle of headliner a thing that doesn't change that much. 00:04:56.866 --> 00:05:03.096 align:middle And there is a news ticker which maybe is even fed from the user profile because it knows 00:05:03.096 --> 00:05:07.756 align:middle that you like sports, so the news ticker is full of sports or you like international politics, 00:05:07.756 --> 00:05:09.656 align:middle so that's what they put in there. 00:05:10.686 --> 00:05:17.486 align:middle And such a page will have a high load so caching would be very beneficial, 00:05:18.206 --> 00:05:22.836 align:middle but you can't cache this with the naive approach 00:05:22.836 --> 00:05:26.746 align:middle because then everybody would see exactly this page of whoever happened 00:05:26.826 --> 00:05:29.756 align:middle to access it, which doesn't work. 00:05:31.396 --> 00:05:38.246 align:middle Another example, I guess most of you have seen GitHub and use the GitHub interface. 00:05:39.076 --> 00:05:42.406 align:middle Again, like most of this stuff is the same for everybody. 00:05:42.986 --> 00:05:46.946 align:middle You have a issue, you have the state of the issue information. 00:05:48.266 --> 00:05:50.976 align:middle Again, you have this login information. 00:05:52.636 --> 00:05:58.366 align:middle Then you have some something that is like, this is specific to you, 00:05:58.366 --> 00:06:03.166 align:middle but it's going to be the same on every page, but then this is specific to you and it depends 00:06:03.166 --> 00:06:05.346 align:middle on which repository page you're on. 00:06:05.706 --> 00:06:08.346 align:middle You can watch this repository or unwatch it. 00:06:08.416 --> 00:06:19.536 align:middle And then the green, like all these buttons to edit is about your permissions on the systems. 00:06:19.536 --> 00:06:20.696 align:middle It's not really personal. 00:06:21.156 --> 00:06:25.986 align:middle Like, if two people are allowed to edit, they will see the same thing there, 00:06:26.466 --> 00:06:29.146 align:middle but if you're not allowed to edit, you will see something different. 00:06:32.856 --> 00:06:38.956 align:middle So after that introduction, let's look at some options, some alternatives we have 00:06:39.516 --> 00:06:42.626 align:middle when when we have this kind of content and we want to cache. 00:06:43.696 --> 00:06:51.136 align:middle So first one is kind of the, if you can do that and do it because it's much easier: 00:06:51.636 --> 00:06:57.286 align:middle avoid sessions or if you have a kind of CMS thing with a form somewhere, 00:06:57.926 --> 00:07:03.456 align:middle maybe just not cache that one page with the form and you have the session for handling that form. 00:07:03.456 --> 00:07:08.576 align:middle But once that page is done, remove the session and the session, 00:07:08.576 --> 00:07:13.186 align:middle remove the session cookies again so that the rest of the page remains cacheable. 00:07:13.816 --> 00:07:26.006 align:middle I call that cheating with JavaScript when you have, you said some information 00:07:26.006 --> 00:07:32.826 align:middle and then you deliver static pages and have JavaScript for changing little bits of the page. 00:07:34.136 --> 00:07:44.086 align:middle Then the kind of tricky approach of caching, even though there is cookies 00:07:44.086 --> 00:07:53.656 align:middle or caching per user - we're gonna come to that later - and finally the user context idea 00:07:53.656 --> 00:07:59.336 align:middle of where you cache, not by individual user, but somehow define groups 00:07:59.336 --> 00:08:01.716 align:middle of users that have the same shared cache. 00:08:04.256 --> 00:08:05.806 align:middle So avoiding sessions. 00:08:08.236 --> 00:08:14.906 align:middle The like the the thing maybe to say that explicitly, as soon as there is a cookie, 00:08:15.456 --> 00:08:21.036 align:middle a normal cache will say: "I will stop caching" because the cookie is individual. 00:08:21.036 --> 00:08:24.936 align:middle It's probably meaning that everybody gets something different so I shouldn't cache. 00:08:26.126 --> 00:08:30.726 align:middle And with this approach you would leave that behavior. 00:08:30.916 --> 00:08:36.306 align:middle So if there is a cookie, there is no caching, but if, if you don't need the session, 00:08:37.276 --> 00:08:41.446 align:middle you would go and delete the cookie immediately so that there is no session. 00:08:42.446 --> 00:08:51.976 align:middle One thing on, on Symfony, if you use the flash messages, that triggers a session just 00:08:51.976 --> 00:08:57.186 align:middle if you do app.flashes, that thing in it initializes the session. 00:08:57.186 --> 00:09:02.316 align:middle So if there is no session, the response will set the session cookie and you stop caching. 00:09:03.056 --> 00:09:07.656 align:middle So you could check like does the request... 00:09:08.386 --> 00:09:09.386 align:middle did have a session? 00:09:09.386 --> 00:09:10.636 align:middle So should we do that? 00:09:10.636 --> 00:09:13.086 align:middle And if there is no session there will be no flash messages 00:09:13.086 --> 00:09:16.416 align:middle because the flash messages are stored in the session. 00:09:16.936 --> 00:09:23.576 align:middle And like in general if you do this you will have to check your application if it happens 00:09:23.676 --> 00:09:27.576 align:middle to somehow start sessions and then go figure out how to not make it do that. 00:09:28.526 --> 00:09:29.896 align:middle If you don't need the session. 00:09:32.696 --> 00:09:37.876 align:middle Another thing you will need to do, so this is the Varnish configuration language, 00:09:39.146 --> 00:09:41.686 align:middle you would want to clean up the cookie 00:09:42.166 --> 00:09:47.436 align:middle so that it only has the php session id in it and not any other stuff. 00:09:47.436 --> 00:09:50.206 align:middle Like typically if you have Google Analytics on your page, 00:09:50.596 --> 00:09:56.286 align:middle there will be some random cookie things that actually only the client side cares about, 00:09:56.806 --> 00:10:00.896 align:middle but that can be sent to the server and the... 00:10:01.236 --> 00:10:06.786 align:middle Varnish or other caches don't try to guess what exactly the cookies mean. 00:10:07.686 --> 00:10:09.526 align:middle So it will see, "oh there is some cookie" 00:10:09.526 --> 00:10:12.106 align:middle and it changes all the time so I'm not going to cache that. 00:10:12.796 --> 00:10:16.876 align:middle So what you do is have this regular expression 00:10:16.876 --> 00:10:21.076 align:middle to extract only the session id out of the cookie and keep that. 00:10:21.976 --> 00:10:25.566 align:middle And then if there is no session id, you would unset the cookie. 00:10:31.956 --> 00:10:33.486 align:middle So far so good. 00:10:34.256 --> 00:10:42.526 align:middle Cool. Then if we move the logic to the frontend, so the cheating is not nice to say. 00:10:42.526 --> 00:10:45.306 align:middle It's not really cheating, it's just a solution 00:10:45.306 --> 00:10:49.956 align:middle where you can still cache even though there is some things different. 00:10:50.706 --> 00:10:56.086 align:middle So basically when you log in you would set some kind of cookie that the JavaScript 00:10:56.086 --> 00:10:58.436 align:middle and knows oh this user is logged in now. 00:10:59.356 --> 00:11:05.566 align:middle And with the thing that I showed before you remove the cookie in the requests, 00:11:05.566 --> 00:11:10.516 align:middle you would even remove the session cookie for this approach. 00:11:11.366 --> 00:11:16.796 align:middle So the user is logged in, but then on most routes the session cookie is removed 00:11:16.796 --> 00:11:19.176 align:middle and everybody gets the same page. 00:11:20.036 --> 00:11:23.466 align:middle But then, uh, in the frontend, in JavaScript, 00:11:23.466 --> 00:11:27.306 align:middle when the page is loaded, you would change the page. 00:11:27.306 --> 00:11:30.586 align:middle So the rendering would include all the editing buttons. 00:11:30.586 --> 00:11:33.216 align:middle For example, if you, if we take that GitHub example, 00:11:33.296 --> 00:11:38.166 align:middle we would include all the editing buttons and then have JavaScript show them 00:11:38.166 --> 00:11:40.576 align:middle or not show them depending on what's going on. 00:11:41.856 --> 00:11:45.726 align:middle Or for example, if you have this, say you're logged in - "Hello David" - 00:11:46.736 --> 00:11:49.776 align:middle you could store the information that I'm called David in a cookie 00:11:50.246 --> 00:11:54.986 align:middle and then whenever the page is loaded, have JavaScript replace the login button 00:11:54.986 --> 00:11:57.176 align:middle with "Hello David" and the link to the profile. 00:11:57.176 --> 00:12:03.306 align:middle And then if I click the link to the profile, the server would not ignore the cookie 00:12:03.306 --> 00:12:06.976 align:middle and have an actual session and not cache that because that's my profile editing - 00:12:06.976 --> 00:12:08.876 align:middle there is no point in caching that part. 00:12:09.296 --> 00:12:16.016 align:middle I think that's really useful when you have these like small bits of a page that change 00:12:16.016 --> 00:12:22.716 align:middle or you have the login on a otherwise pretty static page, that's a useful approach. 00:12:23.256 --> 00:12:27.656 align:middle You get fine-grain control over what to show. 00:12:27.656 --> 00:12:29.296 align:middle You can cache a lot of things. 00:12:30.936 --> 00:12:34.356 align:middle You don't have network overhead with this, uh, and the backend, 00:12:34.356 --> 00:12:39.146 align:middle doesn't have any additional load from it and you can handle complex user interfaces. 00:12:40.956 --> 00:12:45.766 align:middle On the downside, the templating gets more complicated and you would, 00:12:46.546 --> 00:12:52.626 align:middle you would also in like put more things into the page then needed 00:12:52.626 --> 00:12:55.186 align:middle on any specific for any specific user. 00:12:55.186 --> 00:12:57.326 align:middle It's like everything for everybody. 00:12:57.826 --> 00:13:00.656 align:middle It can be a bit tricky to maintain. 00:13:01.836 --> 00:13:07.486 align:middle And if you need additional data, for example, if you, if the editing would show you some kind 00:13:07.486 --> 00:13:14.726 align:middle of list that non logged in, users are not allowed to know of - like a list of options 00:13:15.846 --> 00:13:18.176 align:middle and you don't want to leak that information - 00:13:18.336 --> 00:13:23.596 align:middle you will need to add additional calls to fetch that data and so on. 00:13:23.596 --> 00:13:25.836 align:middle And then suddenly it becomes complicated. 00:13:25.946 --> 00:13:31.886 align:middle Again, kind of similar, you could use AJAX. 00:13:32.366 --> 00:13:37.896 align:middle So say we have these parts of the page that are the same and cached, 00:13:37.896 --> 00:13:42.886 align:middle and then we just have the AJAX include to fetch something with the session 00:13:43.106 --> 00:13:47.526 align:middle that is depending on the session. 00:13:50.986 --> 00:13:57.806 align:middle Yep, so that would be executed after the page is displayed. 00:13:57.806 --> 00:14:02.746 align:middle So if it's a little information, that's not the thing the user wants to see first. 00:14:02.746 --> 00:14:03.426 align:middle It's okay. 00:14:04.676 --> 00:14:10.616 align:middle Um, but if it's like the main thing, you have this wobbly experience of the page loads 00:14:10.616 --> 00:14:12.776 align:middle and then information starts plopping in. 00:14:14.086 --> 00:14:18.376 align:middle And you'll potentially end up with lots of requests to the backend 00:14:19.306 --> 00:14:21.106 align:middle and again, you complicate things. 00:14:29.806 --> 00:14:36.106 align:middle So overall it's similar to the previous approach where you, 00:14:36.696 --> 00:14:41.966 align:middle kinda make your application a bit more messy to optimize it for the caching. 00:14:44.986 --> 00:14:54.986 align:middle Now you can force caching even if there is a cookie with Varnish, um, 00:14:56.206 --> 00:14:59.936 align:middle but it's extremely easy to trade problems. 00:14:59.936 --> 00:15:05.906 align:middle Like if you cache something and the, and that something really depended on the user, 00:15:06.496 --> 00:15:10.386 align:middle then the next user would see the same thing even though he's a different person. 00:15:11.466 --> 00:15:14.206 align:middle So you want to really avoid that. 00:15:14.916 --> 00:15:21.296 align:middle The backend would in this case needs to control what should be cached. 00:15:21.826 --> 00:15:26.926 align:middle So if it's individual, it really has to, to set this no-cache header. 00:15:29.446 --> 00:15:34.106 align:middle You could cache things depending on the session by saying it's cacheable, 00:15:34.106 --> 00:15:40.686 align:middle but it varies on the cookies or the Vary header says: if this header is the same 00:15:40.686 --> 00:15:43.786 align:middle in another request, then the cache is okay. 00:15:43.786 --> 00:15:49.646 align:middle But if the header is different than even the same URL is not the same cache. 00:15:49.646 --> 00:15:50.096 align:middle Like it's... 00:15:50.186 --> 00:15:51.916 align:middle the cache is then calculated... 00:15:52.486 --> 00:15:58.376 align:middle the identity of the cache is the URL plus that Vary information. 00:16:00.856 --> 00:16:01.966 align:middle So that could work. 00:16:01.966 --> 00:16:08.866 align:middle If you have this AJAX call to show my login status, for example, that would be the same. 00:16:09.246 --> 00:16:14.096 align:middle When I do the call with my cookie, it's going to be the same all the time and I will do 00:16:14.096 --> 00:16:16.436 align:middle that call a lot because I do it on every page. 00:16:17.496 --> 00:16:19.956 align:middle So that would be a place where you can use that. 00:16:20.956 --> 00:16:25.946 align:middle If you put Vary on Cookie for everything, you better remove the cache 00:16:25.986 --> 00:16:29.676 align:middle because there will never be any cache hits basically. 00:16:30.256 --> 00:16:31.916 align:middle Because if you... 00:16:31.916 --> 00:16:37.526 align:middle like, every user will have a different cookie because the different session 00:16:38.286 --> 00:16:43.556 align:middle and then everybody will see, like every request will be different 00:16:43.556 --> 00:16:45.766 align:middle and you have no almost no cache hits. 00:16:46.496 --> 00:16:50.016 align:middle And if it's about the same user accessing the same page again, 00:16:50.016 --> 00:16:53.906 align:middle then you better make the browser cache that then your varnish. 00:16:54.826 --> 00:16:58.106 align:middle So Vary cookie is useful in special cases. 00:16:59.456 --> 00:17:06.266 align:middle And then if it's something that doesn't depend on the session at all, you would just say: 00:17:06.806 --> 00:17:10.216 align:middle cache it - it can be cached, even though there was a cookie. 00:17:10.216 --> 00:17:18.166 align:middle If you want to do that in Symfony, you will have to explicitly tell Symfony: 00:17:18.166 --> 00:17:21.376 align:middle I know what I'm doing, since version 3.4. 00:17:21.376 --> 00:17:25.306 align:middle Before it was, if you had a session and then you set the header 00:17:25.306 --> 00:17:28.336 align:middle "this can be cached", it would transmit that. 00:17:28.336 --> 00:17:31.796 align:middle And then it would be Varnish that said like: "oh, that looks fishy, I don't cache it." 00:17:32.426 --> 00:17:40.536 align:middle But now Symfony itself will, as soon as there is a session, it will set the cache headers 00:17:40.536 --> 00:17:43.066 align:middle to make the, the response not be cacheable. 00:17:44.416 --> 00:17:51.116 align:middle And to disable that behavior you have to, to set this kind of magic header 00:17:51.116 --> 00:17:53.706 align:middle to tell Symfony don't override my headers. 00:17:53.706 --> 00:17:57.336 align:middle I actually, if I say cache then I, I wanted to say that. 00:17:57.336 --> 00:17:58.316 align:middle I know what I'm doing. 00:17:58.876 --> 00:18:05.296 align:middle And then on the Varnish side, so this is the default behavior. 00:18:06.796 --> 00:18:11.666 align:middle Varnish will see is the request even a GET or a HEAD request 00:18:11.666 --> 00:18:14.456 align:middle and if not pass means don't try to cache. 00:18:15.566 --> 00:18:20.136 align:middle And if the request is not a GET or a HEAD request then there is no point in caching. 00:18:21.656 --> 00:18:27.456 align:middle And then by default the next step is it looks at the Authorization header which is used for the, 00:18:27.816 --> 00:18:30.616 align:middle like these pop up basic password thing. 00:18:31.196 --> 00:18:32.596 align:middle Or if there is cookies. 00:18:33.176 --> 00:18:36.366 align:middle And if there is any, then it also decides pass. 00:18:37.016 --> 00:18:41.786 align:middle And then the last line where it says hash is saying 00:18:41.846 --> 00:18:45.826 align:middle in all other cases I want to try do cache look up. 00:18:46.796 --> 00:18:51.976 align:middle Now if you want to cache or have the possibility to cache, 00:18:52.106 --> 00:18:57.106 align:middle even if you have cookies, you would change this method. 00:18:57.106 --> 00:18:59.206 align:middle You will override that in your own vcl. 00:19:00.056 --> 00:19:03.186 align:middle You keep the thing about the GET and the HEAD because you still don't want 00:19:03.186 --> 00:19:05.116 align:middle to cache POST requests or whatever. 00:19:06.166 --> 00:19:09.416 align:middle But then you don't check for a Cookie or Authorization header, 00:19:09.416 --> 00:19:11.616 align:middle you would just say: now try caching. 00:19:16.876 --> 00:19:21.036 align:middle Now, this thing can come in handy with edge side includes, 00:19:21.446 --> 00:19:26.216 align:middle which is a bit like the AJAX thing we discussed before, but on server side. 00:19:27.866 --> 00:19:38.496 align:middle So, it's um, your response that the backend would deliver, instead of rendering everything 00:19:38.496 --> 00:19:45.166 align:middle in one page, it includes URLs to say like: "Here, please put in - copy paste in - 00:19:45.166 --> 00:19:47.626 align:middle this bit that you get from this other URL." 00:19:47.656 --> 00:19:53.436 align:middle And then Varnish will fetch, like look at that and fetch all separate elements and stick 00:19:53.436 --> 00:19:55.676 align:middle that together and then send it to the client. 00:19:56.576 --> 00:20:01.966 align:middle And the very interesting thing for us here is that each bit, like the main frame 00:20:01.966 --> 00:20:05.886 align:middle and then all embedded parts have separate caches. 00:20:05.926 --> 00:20:08.566 align:middle So each of them can have different cache rules. 00:20:11.046 --> 00:20:19.006 align:middle So, for example, you could say this, this login thing, we cached this, would Vary on Cookie 00:20:20.116 --> 00:20:23.736 align:middle and then the rest of the page doesn't depend on the Cookie. 00:20:25.086 --> 00:20:32.196 align:middle And then Varnish will have two parts like this login thing and the actual page. 00:20:32.986 --> 00:20:36.456 align:middle And the actual page is cached as soon as anybody has looked at it. 00:20:36.456 --> 00:20:39.166 align:middle And your login thing is cached as soon as you logged in. 00:20:40.156 --> 00:20:43.686 align:middle So you increase the chances that you have a cache hit. 00:20:46.516 --> 00:20:49.786 align:middle Symfony has built in support for the edge side includes. 00:20:51.226 --> 00:21:00.456 align:middle So in, in HTML, like what it will output to you is this. 00:21:00.866 --> 00:21:06.016 align:middle So it has this <esi:include thing and this is a URL 00:21:07.066 --> 00:21:10.186 align:middle that in this case would be relative to the URL of the document. 00:21:13.256 --> 00:21:20.546 align:middle And, so the cool thing about this is we have separate caching for each fragment. 00:21:22.316 --> 00:21:26.146 align:middle It's on the server side, so search engines will see one page 00:21:26.146 --> 00:21:29.606 align:middle and not some JavaScript thing stitched together. 00:21:30.776 --> 00:21:33.796 align:middle And in your application it doesn't add a lot of overhead. 00:21:35.886 --> 00:21:41.696 align:middle The, like one issue with this is every single edge side include has 00:21:41.696 --> 00:21:44.786 align:middle to be resolved before the response can be sent out. 00:21:46.026 --> 00:21:50.856 align:middle And with the normal Varnish server it will resolve them one by one. 00:21:51.336 --> 00:21:56.266 align:middle So if you have something with like a lot of includes that can become really slow. 00:21:58.096 --> 00:22:01.656 align:middle There is Varnish Plus, which is a commercial version of Varnish 00:22:01.656 --> 00:22:07.186 align:middle and there they offer this additional feature that the ESI can be resolved in parallel. 00:22:07.666 --> 00:22:12.226 align:middle You can configure like do at most whatever, 10 requests in parallel. 00:22:13.396 --> 00:22:14.546 align:middle So it's doable. 00:22:19.226 --> 00:22:25.416 align:middle In Symfony you will activate in the configuration: you say, I want to do ESI 00:22:25.416 --> 00:22:31.956 align:middle and these, like, sub parts of a page should be exposed at this route 00:22:31.956 --> 00:22:34.806 align:middle that you can specify, for example _fragment. 00:22:36.196 --> 00:22:42.876 align:middle The thing is this will, with a naming convention, expose controller actions, 00:22:43.556 --> 00:22:45.766 align:middle even actions that don't have a route. 00:22:45.766 --> 00:22:50.916 align:middle So you really want to make sure that this route is not accessible from outside. 00:22:50.916 --> 00:22:56.376 align:middle Varnish must be allowed to access it, but the public internet should not have access 00:22:56.376 --> 00:23:01.106 align:middle to that fragments route, otherwise they can try and call controllers with weird stuff 00:23:01.106 --> 00:23:03.536 align:middle and you will lose control of what's going on. 00:23:04.076 --> 00:23:13.356 align:middle And then in Twig you would included like this: say render_esi() 00:23:13.966 --> 00:23:17.176 align:middle and specify the controller, you can specify parameters. 00:23:17.616 --> 00:23:24.416 align:middle These parameters, um, can't be objects because they need to be included, 00:23:24.416 --> 00:23:29.356 align:middle it builds a URL from this which must be some sort of string that then Varnish will send. 00:23:30.356 --> 00:23:33.606 align:middle And it's also not the same PHP process that will handle this. 00:23:33.676 --> 00:23:37.736 align:middle So if you, I don't know, if you have some information in the container 00:23:37.736 --> 00:23:43.436 align:middle or if you did some globals, I don't know, that's not gonna work with ESI 00:23:43.476 --> 00:23:46.356 align:middle because it's a separate request that hits the backend. 00:23:46.356 --> 00:23:49.956 align:middle If you have a multi-node setup, it could hit the different node even. 00:23:51.676 --> 00:23:54.116 align:middle So it's really a separate request. 00:23:54.116 --> 00:24:02.006 align:middle So you have to be careful if your application has too much state in it. 00:24:04.416 --> 00:24:12.756 align:middle Now, even with ESI, we still either cache, globally for everybody or we cache individually 00:24:12.756 --> 00:24:15.106 align:middle with the session cookie for one single user. 00:24:17.756 --> 00:24:21.836 align:middle Now the rest of the talk I want to spend talking on user context. 00:24:23.626 --> 00:24:31.316 align:middle So like, example from traveling where they say... 00:24:32.176 --> 00:24:39.526 align:middle we just take this deciding criteria: if you're UK or have a European Union passport, 00:24:39.846 --> 00:24:44.366 align:middle then go this way and everybody else goes somewhere else. 00:24:45.676 --> 00:24:49.396 align:middle And so the distinction is not on the individual passport but it's just: 00:24:49.526 --> 00:24:54.576 align:middle is it an EU passport or a UK passport. 00:24:55.086 --> 00:25:03.106 align:middle So we try to build groups with somehow the same permissions or the same properties. 00:25:04.726 --> 00:25:08.776 align:middle In Symfony, for example, it could be the groups of a user, 00:25:09.566 --> 00:25:12.726 align:middle because Symfony security has this concept of groups already. 00:25:14.126 --> 00:25:19.806 align:middle This can be implemented quite transparently: the reverse proxy does the job 00:25:20.066 --> 00:25:23.976 align:middle and the application doesn't really need to know about it that much. 00:25:26.156 --> 00:25:30.726 align:middle The Hash itself is individual for every user. 00:25:32.286 --> 00:25:38.506 align:middle And, yea, we can like build our own rules how we built that hash. 00:25:38.996 --> 00:25:47.026 align:middle And then again the hash look up will be a request to the backend, but we can cache that. 00:25:47.026 --> 00:25:54.946 align:middle Because if you have a session, like it makes sense if your session, if your hash stays stable 00:25:55.736 --> 00:25:58.216 align:middle as long as your session is going on. 00:25:59.536 --> 00:26:00.476 align:middle So how does that look? 00:26:00.476 --> 00:26:03.746 align:middle We have a request that comes with credentials. 00:26:05.486 --> 00:26:11.146 align:middle And that request, Varnish goes to the web application and says I need a hash 00:26:11.146 --> 00:26:14.396 align:middle for this user sending along the credentials. 00:26:14.886 --> 00:26:18.736 align:middle And it gets back a response with, with that hash. 00:26:19.396 --> 00:26:26.006 align:middle And the Vary, like this response depends again on the Cookie or the Authorization header. 00:26:26.366 --> 00:26:34.776 align:middle And then we do the actual content request and add the, this context hash to the request 00:26:35.876 --> 00:26:41.286 align:middle and if the response really only depends on the hash, on the groups of the user 00:26:41.286 --> 00:26:45.896 align:middle and not on the individual user, it would reply with it varies on that hash. 00:26:46.436 --> 00:26:54.046 align:middle And then if like on the second time this happens, we would have a cache hit. 00:26:55.426 --> 00:27:02.246 align:middle So in a more flow diagram, the browser asks for /welcome 00:27:02.246 --> 00:27:08.126 align:middle and the reverse proxy first gets the hash for the user... 00:27:08.716 --> 00:27:10.866 align:middle would get some hash. 00:27:11.366 --> 00:27:19.036 align:middle And then asks for: I want /welcome with the hash is this and gets a response that says, okay, 00:27:19.036 --> 00:27:22.146 align:middle the page looks like this and it depends on that hash. 00:27:24.006 --> 00:27:31.016 align:middle Now, next time we have a request, if it's the same user, we already have the hash. 00:27:32.156 --> 00:27:36.076 align:middle If it's a page that anybody with the same hash, so anybody with the same set 00:27:36.076 --> 00:27:41.056 align:middle of permissions already asked for, we can have a cache hit and say, okay, 00:27:41.056 --> 00:27:45.586 align:middle so here you get this same page that the other user got. 00:27:46.196 --> 00:27:55.556 align:middle And the thing is you're, the web server when it handles the actual request it, 00:27:55.656 --> 00:28:00.516 align:middle doesn't need to know about this hash thing, it just takes the credentials of the current user 00:28:00.836 --> 00:28:04.236 align:middle and builds the page as it builds it for that single user. 00:28:06.036 --> 00:28:10.456 align:middle So you don't need to rewrite your application to to handle it in any special way. 00:28:10.456 --> 00:28:14.046 align:middle You only, at the end, you need to decide is what I did... 00:28:14.446 --> 00:28:18.246 align:middle did that only depend on the groups of the user or was it individual 00:28:18.806 --> 00:28:21.406 align:middle so that you set the correct Vary information. 00:28:27.006 --> 00:28:29.846 align:middle In Varnish side, it would look like this. 00:28:30.746 --> 00:28:35.586 align:middle So, when we receive a request, we... 00:28:36.366 --> 00:28:40.966 align:middle so here, I use the curl Varnish module, which allows Varnish 00:28:40.966 --> 00:28:45.786 align:middle to send a web request before forwarding the actual request. 00:28:45.856 --> 00:28:54.266 align:middle So here we create a new request and we add a host header, I call auth - that's just the name 00:28:54.266 --> 00:28:59.856 align:middle of the server that handles authentication and do a request 00:28:59.856 --> 00:29:02.626 align:middle on ourselves with all the original headers. 00:29:05.106 --> 00:29:14.676 align:middle And then if the, if the response is not 200, we return with the response status code, 00:29:14.676 --> 00:29:17.516 align:middle most likely that was the credentials were invalid. 00:29:18.546 --> 00:29:27.966 align:middle And otherwise we copy the, this user context thing from the response that we got 00:29:28.596 --> 00:29:33.456 align:middle onto the request and then continue and send the original request 00:29:33.456 --> 00:29:35.986 align:middle to the backend with that hash on it. 00:29:38.696 --> 00:29:46.216 align:middle And...the reason we don't go directly to the backend here is that we want 00:29:46.216 --> 00:29:52.706 align:middle to also cache the context lookup and with setting this auth header we can, 00:29:53.906 --> 00:29:58.566 align:middle as a first thing in the receive, we can say: "oh do you ask for auth? 00:29:58.616 --> 00:30:00.746 align:middle Then, if you're... 00:30:01.706 --> 00:30:05.166 align:middle if I am myself, like if I was just doing a request on myself, 00:30:05.626 --> 00:30:11.306 align:middle then we go to the backend and force the cache lookup. 00:30:12.376 --> 00:30:16.996 align:middle And if it was any other client asking for getting a hash, 00:30:16.996 --> 00:30:19.116 align:middle we stop that because it makes no sense. 00:30:19.736 --> 00:30:22.606 align:middle It's likely somebody trying to hack into our system. 00:30:26.856 --> 00:30:34.246 align:middle And then finally on Symfony side, we could do something like this. 00:30:34.246 --> 00:30:45.836 align:middle We take the roles of the current user and then, build a hash from that. 00:30:46.026 --> 00:30:51.156 align:middle So this code is built on top of the FOSHttpCache HTTP cache library 00:30:51.956 --> 00:30:54.436 align:middle which provides tools for, doing this. 00:30:56.376 --> 00:31:01.106 align:middle And actually like this bit with the user roles that's already provided in the library. 00:31:02.606 --> 00:31:06.756 align:middle So writing your own thing would be if you need something else than the user roles. 00:31:07.386 --> 00:31:12.236 align:middle Does that make sense so far? 00:31:12.716 --> 00:31:15.836 align:middle Any questions at this point or confusion? 00:31:17.376 --> 00:31:18.176 align:middle Nope. Cool. 00:31:19.126 --> 00:31:23.206 align:middle Then I'm going to wrap up at this point. 00:31:24.426 --> 00:31:29.926 align:middle I presented a bunch of different approaches or solutions, 00:31:30.866 --> 00:31:34.746 align:middle but often they can, they can be combined. 00:31:34.746 --> 00:31:41.526 align:middle So for example, you could cache things even with cookies and use edge side includes for that 00:31:41.666 --> 00:31:50.456 align:middle or use AJAX to do it on client side or mix user context with the AJAX things 00:31:50.456 --> 00:31:56.596 align:middle or even another thing, you move like a lot more of the application to the frontend 00:31:57.346 --> 00:31:59.496 align:middle and build more of an API on the backend. 00:32:00.496 --> 00:32:07.596 align:middle And if you have small enough endpoints possibly you could increase the cache hits 00:32:07.796 --> 00:32:08.766 align:middle with that as well. 00:32:09.126 --> 00:32:16.216 align:middle And of course the whole user context thing, we're using that in an API as well. 00:32:16.216 --> 00:32:19.316 align:middle So with JSON data it works just as well. 00:32:19.316 --> 00:32:25.976 align:middle When you have different API clients with different permissions, that that works fine too. 00:32:28.706 --> 00:32:36.296 align:middle And depending on your scenario, you could be writing your own information provider 00:32:36.296 --> 00:32:37.786 align:middle for that context hash. 00:32:39.246 --> 00:32:45.176 align:middle For example, the, the thing from the beginning, the newspaper where it has the temperature 00:32:46.056 --> 00:32:50.416 align:middle where you would say the hash actually is your geographical region. 00:32:51.886 --> 00:32:55.316 align:middle Or maybe you have a localized page for every country. 00:32:55.896 --> 00:33:03.096 align:middle Then you could do a hash based on, on, what is your location from the IP 00:33:03.096 --> 00:33:06.306 align:middle and whatever tools you have available to determine that. 00:33:07.306 --> 00:33:11.216 align:middle Or based on the user agent or on some client capabilities. 00:33:11.826 --> 00:33:15.776 align:middle Or maybe even for A/B testing where you would set some kind of A/B cookie 00:33:15.776 --> 00:33:21.616 align:middle and then make a hash based on that and have caching of your A/B testing. 00:33:27.776 --> 00:33:33.756 align:middle And as I mentioned before, there is a FOSHttpCacheBundle 00:33:33.756 --> 00:33:36.116 align:middle that I'm maintaining together with others. 00:33:36.956 --> 00:33:44.816 align:middle Which besides having all this stuff for this user context handling, it also has support 00:33:44.816 --> 00:33:53.176 align:middle for cache tagging where you mark caches as: this page contains this or that article maybe 00:33:53.176 --> 00:33:57.206 align:middle and when you want to invalidate you can say invalidate everything 00:33:57.206 --> 00:33:58.956 align:middle that is tagged with this information. 00:34:00.706 --> 00:34:06.576 align:middle And it contains a system where you can, in your Symfony application, you can record, okay, 00:34:06.576 --> 00:34:10.866 align:middle after this POST request I want to invalidate this and that cache. 00:34:11.396 --> 00:34:22.516 align:middle It supports annotations on your controllers for, for the caching headers and it also has a system 00:34:22.516 --> 00:34:28.186 align:middle of request matchers where you configure a on this URL and everything 00:34:28.426 --> 00:34:33.736 align:middle that matches this pattern, I want to set some cache headers. 00:34:33.736 --> 00:34:39.566 align:middle Like all old things under /user are no-cache or all things 00:34:39.566 --> 00:34:42.386 align:middle under /static are always cached, things like that. 00:34:43.156 --> 00:34:47.206 align:middle Because with plain Symfony we have the Response object and you would have to set 00:34:48.046 --> 00:34:52.626 align:middle on the Response object cache headers in every controller and if you have lots 00:34:52.626 --> 00:34:55.456 align:middle of controller actions, this can be useful. 00:34:56.046 --> 00:35:01.156 align:middle Yep, and with that I'm at the end. 00:35:01.156 --> 00:35:03.856 align:middle I'm open for questions if there is any. 00:35:04.376 --> 00:35:06.216 align:middle Yes, please. 00:35:06.376 --> 00:35:10.096 align:middle Do we have a microphone? 00:35:11.696 --> 00:35:18.366 align:middle Oh, that's, that's too big to see. 00:35:21.646 --> 00:35:29.126 align:middle By the way, we use Varnish and it handles millions of requests and it's awesome for us. 00:35:29.126 --> 00:35:31.086 align:middle Anything for using it locally? 00:35:31.146 --> 00:35:38.126 align:middle Because when we are trying to, to go the homepage or stuff like that, it's really painful 00:35:38.126 --> 00:35:45.576 align:middle to always try to add parameters to invalidate the cache locally and stuff like that. 00:35:45.576 --> 00:35:49.976 align:middle So for us, when we work locally we usually don't put the cache in front. 00:35:50.786 --> 00:35:57.656 align:middle Like we go through, to the Symfony application directly to, to avoid the caching. 00:35:57.656 --> 00:36:01.686 align:middle Yeah, but we use the ESI include. 00:36:02.056 --> 00:36:05.176 align:middle And for us we, we need to test it locally. 00:36:05.176 --> 00:36:11.156 align:middle Otherwise in staging or live the behavior will be different. 00:36:11.476 --> 00:36:15.666 align:middle So if you use ESI with Symfony, then Symfony will see, 00:36:15.886 --> 00:36:18.206 align:middle like if you use the thing that I showed... 00:36:18.206 --> 00:36:19.706 align:middle yep, this one. 00:36:20.806 --> 00:36:36.026 align:middle So if you use this construct Symfony will actually see if the client is capable of ESI 00:36:36.336 --> 00:36:40.316 align:middle and if it's not capable, Symfony itself would resolve the ESI includes. 00:36:41.426 --> 00:36:49.716 align:middle So in that case it could, it should be able to render the whole page for you - 00:36:50.216 --> 00:36:53.926 align:middle without Varnish - so that, that should work. 00:36:54.556 --> 00:36:59.916 align:middle The other thing you could possibly do - are you on Symfony or is it something else? 00:37:00.336 --> 00:37:09.066 align:middle No. No. Okay, then one thing you maybe could do is define a separate Varnish configuration 00:37:09.776 --> 00:37:15.196 align:middle for that case where maybe you, in the receive, before it does the hash, 00:37:15.326 --> 00:37:18.196 align:middle like this return hash thing to say I want a cache look up. 00:37:18.796 --> 00:37:23.546 align:middle You could put: I actually want to pass, I never want to do a cache look up. 00:37:23.776 --> 00:37:28.366 align:middle And then you can always go through Varnish and have all the logic the same, 00:37:28.366 --> 00:37:30.546 align:middle but only this little bit is different. 00:37:31.156 --> 00:37:32.706 align:middle And then it wouldn't cache ever. 00:37:32.706 --> 00:37:36.786 align:middle I think that's actually a good idea because you have a system 00:37:36.786 --> 00:37:40.176 align:middle that is very similar to production. 00:37:41.186 --> 00:37:51.426 align:middle Our idea is to have the same, the same system as live. 00:37:51.706 --> 00:37:53.856 align:middle Okay. Can you pass the cube over. 00:37:55.276 --> 00:37:55.856 align:middle It's very light. 00:37:55.946 --> 00:37:59.496 align:middle Throw it. Hi. 00:37:59.496 --> 00:38:04.666 align:middle I'm working with Varnish for a couple years right now and coming from another framework 00:38:04.666 --> 00:38:09.946 align:middle and just edit the esi:include in this other framework. 00:38:10.646 --> 00:38:17.356 align:middle And I'm, I'm using the esi:remove part for, for dealing with local development 00:38:17.466 --> 00:38:21.386 align:middle because this is what I see when I'm not using varnish. 00:38:21.956 --> 00:38:28.996 align:middle So I edit the real rendering and the remove path depending on, some, server environments, 00:38:29.896 --> 00:38:34.086 align:middle the filling out of the environment in the local development mode, 00:38:34.726 --> 00:38:40.006 align:middle and then adding those esi:remove tags with the real content, 00:38:40.236 --> 00:38:43.816 align:middle but still providing esi:include tags, whether you... 00:38:45.056 --> 00:38:51.136 align:middle this is how I can just switch easily between using varnish with the include path 00:38:51.716 --> 00:38:54.926 align:middle and having a local copy with the real output. 00:38:55.696 --> 00:38:59.316 align:middle So maybe this is some kind of solution you want to use as well. 00:38:59.886 --> 00:39:06.346 align:middle And if you want and have just a couple of minutes I can show you on the evening what I, 00:39:07.036 --> 00:39:09.586 align:middle what I did in this other framework. 00:39:11.976 --> 00:39:14.046 align:middle Thanks a lot. 00:39:16.156 --> 00:39:17.326 align:middle Any other questions? 00:39:19.346 --> 00:39:28.406 align:middle Hello? Is it possible to use Varnish with ESI in a JSON request? 00:39:29.046 --> 00:39:31.946 align:middle Yes. It is. 00:39:32.506 --> 00:39:40.796 align:middle So, the only thing you have to look at, you need to set some kind of flag 00:39:41.966 --> 00:39:47.616 align:middle because otherwise it's thinking, oh, this is stuff I don't know. 00:39:47.666 --> 00:39:49.816 align:middle So I'm not gonna... 00:39:49.816 --> 00:39:51.996 align:middle Sorry, if you do ESI... 00:39:52.486 --> 00:39:56.356 align:middle the thing is if you would, I don't know, if you have some pdf or some binary format 00:39:56.896 --> 00:40:01.106 align:middle and you do ESI on that, then probably that's not what you want. 00:40:01.106 --> 00:40:05.246 align:middle So Varnish says, oh, this is like binary things I don't know. 00:40:05.536 --> 00:40:11.616 align:middle So you have to set some, uh, some kind of flag in the startup flags to tell it. 00:40:11.616 --> 00:40:15.446 align:middle I want you to do ESI on JSON responses. 00:40:15.446 --> 00:40:21.096 align:middle Otherwise it won't try to do it because it doesn't know if that's what you intended. 00:40:21.936 --> 00:40:22.826 align:middle But it is possible. 00:40:27.806 --> 00:40:29.636 align:middle Hello. Awesome presentation. 00:40:29.896 --> 00:40:30.596 align:middle Thanks. Thank you. 00:40:31.566 --> 00:40:35.476 align:middle I'm wondering about FOSHttpCacheBundle. 00:40:36.136 --> 00:40:41.936 align:middle You said that there is a possibility to annotate, invalidate all, or cache everything. 00:40:42.396 --> 00:40:48.106 align:middle Is there are also option for invalidate some part of cache. 00:40:48.676 --> 00:40:50.076 align:middle Like in this (??) 00:40:50.976 --> 00:40:56.236 align:middle approach invalidate only comments under certain posts. 00:40:56.236 --> 00:40:58.066 align:middle Like [mighty] post. 00:40:59.236 --> 00:41:05.206 align:middle There is. It's um, so we leverage the ban feature of Varnish itself. 00:41:05.206 --> 00:41:09.706 align:middle Like Varnish itself has that as well where you say: I want to invalidate everything 00:41:09.706 --> 00:41:15.826 align:middle that matches a regular expression and you, you can match on the path. 00:41:15.826 --> 00:41:20.896 align:middle You can also match on certain headers, like the domain name or random other headers. 00:41:22.676 --> 00:41:27.946 align:middle That works fine, but if you use it too much, you run into problems because Varnish has 00:41:27.986 --> 00:41:33.476 align:middle to keep like, Varnish might have thousands or hundred thousands of pages in the cache. 00:41:33.836 --> 00:41:37.506 align:middle So when you send that request, it's not gonna go into the cache and look 00:41:37.506 --> 00:41:39.946 align:middle at everything to remove that immediately. 00:41:40.206 --> 00:41:41.686 align:middle But rather it says, oh okay. 00:41:41.686 --> 00:41:48.236 align:middle So I, I take note and whenever a request comes it compares that with this ban 00:41:49.046 --> 00:41:50.806 align:middle or with all the bans that you sent it. 00:41:50.806 --> 00:41:56.826 align:middle And then if one of them matches it said, okay, so this cache entry actually is gone. 00:41:58.256 --> 00:42:01.506 align:middle But that means if you have a lot of bans and a lot of requests, 00:42:01.506 --> 00:42:04.506 align:middle you will slow down your requests and at some point that goes... 00:42:04.506 --> 00:42:08.096 align:middle like we had that for awhile when we accidentally did too many bans, 00:42:09.056 --> 00:42:16.726 align:middle where Varnish would repeatedly be unusably slow suddenly because it has so many things to look 00:42:16.726 --> 00:42:21.696 align:middle at before it can return a response because it has to check like, oh, is it banned? 00:42:21.696 --> 00:42:23.936 align:middle Is it banned with any of these things? 00:42:25.176 --> 00:42:31.136 align:middle So, it exists and it's, it can be useful, but I would be careful when to use it. 00:42:32.136 --> 00:42:38.216 align:middle But the cache tagging, there is a, a Varnish module where it does some sort of binary tree 00:42:38.216 --> 00:42:44.306 align:middle on the caches, so Varnish actually understands the tags and that can be really efficient. 00:42:44.386 --> 00:42:48.946 align:middle So there, if you can tag things, that would be much more efficient 00:42:48.946 --> 00:42:50.426 align:middle if you need to invalidate often. 00:42:51.456 --> 00:42:55.156 align:middle And if it's like very rarely that you say like, oh, whatever, this whole section 00:42:55.156 --> 00:42:59.126 align:middle of the page needs to be invalidated now, but you do that like once a day, 00:42:59.126 --> 00:43:01.196 align:middle whatever, then that's not a problem. 00:43:01.506 --> 00:43:04.756 align:middle But if you have some processes and it does that like hundreds 00:43:04.756 --> 00:43:06.856 align:middle of times an hour, then it's a problem. 00:43:07.726 --> 00:43:08.956 align:middle Thanks. Thank you. 00:43:10.086 --> 00:43:11.116 align:middle Any other questions? 00:43:12.606 --> 00:43:15.476 align:middle Uh, hello. 00:43:16.026 --> 00:43:19.436 align:middle How works Varnish with the https together. 00:43:20.026 --> 00:43:21.016 align:middle Or not working? 00:43:21.106 --> 00:43:29.596 align:middle Um, so the open source Varnish, you would put something in front of it that handles the https 00:43:30.436 --> 00:43:32.406 align:middle because Varnish itself doesn't... 00:43:33.456 --> 00:43:34.386 align:middle like it doesn't... 00:43:35.226 --> 00:43:42.286 align:middle period. The Varnish Plus - the commercial version - there they, they sell some, 00:43:43.576 --> 00:43:47.086 align:middle that they sell, they added something for the https handling. 00:43:48.376 --> 00:43:54.586 align:middle But the, it can make sense to put some Nginx or some, a small... 00:43:54.586 --> 00:43:59.936 align:middle like there is a couple of small proxies that only are really built for that kind of thing. 00:43:59.936 --> 00:44:01.996 align:middle Like just https termination. 00:44:02.316 --> 00:44:04.586 align:middle But Varnish itself doesn't handle it. 00:44:07.216 --> 00:44:12.906 align:middle Alright. Yeah, I think we're closing here and I'm still around. 00:44:13.596 --> 00:44:18.606 align:middle So if you have any more questions, come up and ask me or ask me later today or tonight 00:44:18.776 --> 00:44:25.776 align:middle or tomorrow and have a good lunch.