Django Nginx Cache | Vary Header | Header Directives

hello and welcome to vari  academy my name is xander   in this tutorial we focus in on  nginx cache serving django web pages more specifically in this tutorial we take a  look at the vari header and its role on cache   key generation and that's going to take us down a  path where we start to look at configuring nginx   to ignore specific header data and then it  allows us to go a little bit deeper into   more django specifics in this tutorial we take  a look at how to configure which request headers   a cache mechanism should take into account from   a django project and then also control how caching  is performed using django header directives   to fully engage with the content in this tutorial  it is advised for you to have some general working   knowledge working with a django project and  it would be advisable for you to watch the   previous tutorial in this series so go ahead  if you haven't found the tutorial series so   far go ahead to the main channel get a playlist  and you're looking for the nginx mastery series in this tutorial we do start from baseline code  which we developed in the previous tutorial   and all that obviously has been explained in the  previous tutorial so it'd be well worth having   a look at that and that is tutorial five in this  series so that's the previous tutorial so go ahead   and have a look at that first if you want to know  a little bit more about the baseline settings that   we start with in this tutorial now we are going  to be utilizing docker again in this tutorial   so you're going to need to have docker  installed if you haven't already done so   and here we're using visual studio code and  some extensions so notably we're utilizing the   docker extension in this tutorial just to make  things nice and simple for you to follow along   there are essentially five stages in this  tutorial and i will try and break this down   in the video description so you can skip ahead if  you want to but first of all we're going to start   with a simple setup there is some code which  you'll find a link in the video description go   ahead and download the previous tutorials code  we're going to start from that as a baseline and   then we go ahead and explore the default behavior  so we'll have a look at understanding the default   behavior of utilizing nginx cache serving django  web pages from there we'll delve into the very   header understanding what it is and potentially  then how to configure that as a baseline in nginx   when serving django web pages and then finally we  have a look at some of the different django cache   configurations and options that are available when  building a django project and controlling cash so just before we get started just to recognize  all the members and supporters of this channel   thank you very much it is always very appreciated  if you are thinking about supporting our channel   further you can do through the channel membership  scheme or potentially following us on patreon don't forget to like and subscribe and if you  want to join the community you can follow us on   many of these socials just a little bit of  setup here for this tutorial there is a link   in the video description which will take  you over to the nginx mastery series code   on github and go ahead and clone this down  or just go ahead and download this and what   we're going to need is the part 5 code so  download open up part 5 folder and then   maybe copy that to a new folder the code inside  of there and open that in visual studio code   so once you've gone ahead and opened up part  5 in visual studio code then you're going to   find a range of different files here and  this represents what we've been developing   over the last couple of tutorials now don't  worry if you don't understand this fully at   this point i will explain everything you need  to know to meet the objectives of this tutorial   so let's get this started now you are going  to need docker install because we're going   to start that up shortly uh so go ahead and do  that if you haven't already got docker desktop   right so first thing then we're going to need to  build an environment folder so that's something   that's missing so a new folder dot emv so these  are just some environment variables that django   requires uh it's just how we've set up django um  so here then we're gonna have dev dot emv and then   what you'll find hopefully if not probably  not in the commands here um i was going to   just uh go ahead and copy across the commands  we need for this file here so basically just   uh four different variables that we're going  to set here secret key loud hosts and debug   equals one so that needs to go in here so  django is basically just going to pick up these   environment variables from this  file in order to get django started if you're not familiar with environment variables  it's a way of basically removing some of the   uh critical sensitive information from  the django project and put it into a   firewall area where you can secure and keep it  the data secure away from plain sight so this   is obviously just a demo application right so  with that in place you can use anything for a   secret key um a loud host just make sure it's one  two seven zero zero one and then debug equals one   okay so with that in place uh we can now go ahead  and start this project i do have docker desktop   installed so you can see there's no images on  containers so it's completely fresh so let's go   ahead and just type in python sorry docker compose  and then up and that should go ahead and build   from the compose file and then bring up those  containers so there should be three containers   just ignore the dns containers for now  if you've not seen the previous tutorials   it will be irrelevant in this tutorial but once  everything is up and running um i do have the   docker extension here you can see that all the  containers are running correctly so make sure that   you have this green uh star icon here that  indicates that the containers are working   correctly so from there you just need to type  in one two seven and we don't need the port   you'll just need to run that from one two  seven zero zero one and you can see this   project is really simple um there are three kind  of endpoints here so let's just go to p1 frogs no p1 there we go so there's just two pages here  or endpoints um page one and page two so that   should now be working okay so we've just gone  ahead and created three containers one has a dnf   server which you can just ignore in this tutorial  we have the nginx service in a container and then   we have the gunny g unicorn sorry and django with  just with sqlite within a container and what's   happening here from our browser we're requesting  the web page that's been sent to nginx server   that then requests been forwarded across because  this is a reverse proxy set up here on the nginx   server that gets sent across and then g unicorn  then takes that request and then passes it along   to the django instance at that point django then  checks the your uh request and then serves the   web page now the first time your web page returns  back through the nginx server um nginx goes ahead   and puts a copy of that information into cache and  then goes ahead and serves that page back to the   browser so that's the first time the first request  of a single page the second request requests are   at that page what happens is that your request  will go to the nginx server it matches your   um it matches that request to a cache key in the  cache and then goes ahead and serves that page   from cache so that's currently the setup here  and again the previous tutorial in the previous   tutorial we basically set up this configuration  we're going to be working from this baseline   so let's just take a look if you haven't seen  it the configuration for this and the folder and   files here so we have a docking compose file which  is kind of building all the containers for this   configuration and then in the docker compose file  here we have a few different volumes where we're   mapping over some folders to make it easier for us  to work with some of the configuration files and   one of them is the comfd file here or the default  configuration file here in nginx and basically   what you're looking at here is the configuration  or a current configuration that we've set up for   nginx and you can see that we've set this up for  a reverse proxy uh which means we're basically   we're passing this over to our upstream server  which is on web 8000 port so we're just passing   all the data over to django and that's being  managed and handled by the g unicorn server   okay so we're listening on port 80. um you can see  here what we've set up in the previous tutorial   is that in actual fact we wait for five requests  for the same resource in order for us to then   cache that page so i'm just going to remove  that for now um okay right so you can also   see that the page here the p1 page the proxy  has been turned off so we've disabled the cache   um for that page that was set up in the previous  tutorial so i'm just going to remove that there   from that configuration so we're just going  to cache everything for now right so with that   done let's just go ahead and i'm just going  to use the docker extension here go into my   nginx server attach a shell i'm just i can just  go ahead and just reload this if i wanted to   um the container or i can use the command here  reload so that's just going to reload on the fly   and the configuration so with that done  alternatively you can just go ahead and restart   so here i'm using chrome so we'll go ahead and  just have a look at the default configuration   for this so uh let's go into chrome i'm just  going to go to this page again now we haven't   served page 2 yet so i'm just going to press f12  that's going to bring up the console i'm going   to select the network tab here which is going  to give me information about the page loading   so let's just go ahead and refresh and  you can see that we've said this page here   and what we're looking for again demonstrated in  the previous tutorial explained in the previous   tutorial what we're looking for here is  we're sending across uh x frame options   and it says deny here so this page is being denied  from being cached at the moment uh so let's just   go ahead and go to page two now remember the first  time we serve this page it shouldn't be put into   the cache and you can see here it says x proxy  cache miss so that means that this page hasn't   been served from our proxy server from our nginx  cache and if i go ahead and run this page again   this time because we've made the initial request  that was served and saved then in nginx cache   and this time the page is being served from  nginx cache because we have the x proxy cache hit so that pretty much concludes the setup process  so let's now explore the default behavior of nginx   when saving and serving django web pages so  hopefully we've got the basic understanding here   of this x proxy cache option here um parameter  attribute which is essentially just telling us   whether our page is being served from cache or not  so hit that's indicating that this page is being   served from cache and then basically deny means  maybe we've uh prevented that page from being   cached and then miss being the page hasn't been  served from cache so page one maybe we've already   served this i can't remember uh yeah so here we  go miss so this page hasn't been served remember   it's the first time we requested this page so now  nginx has now saved that into cache so when we   subsequently request this page it should now be  served from cache here we go so it now says x   proxy hit now the reason why we're seeing that  header option is because we've set it here in our   default configuration and header x proxy cache  so that's what is being that's what's returning   this x proxy cache information and of course  we can serve that turn that off in production   as it's really just providing us some diagnostic  information so let's take a look at a potential   problem we have here all right i'm so just going  to go ahead in chrome and create a new incognito   window and then i'll just bring this down a  little bit here and we have this uh side by side   so here we're going to simulate a new user  accessing the same web page now you would imagine   potentially that because we've already saved this  page in cash then the next person who comes along   that page should be served from cash that's kind  of the point of potentially utilizing cash so that   we don't have to send a signal all the way back to  django and process the same request multiple times   it's going to be a lot quicker serving a page from  our cash potentially rather than going through   that whole process so let's just try this out  and see if this works so we're going to need to   actually go into our console um and get that ready  so we'll go ahead and serve that page and now   let's go to the page we've just been to p1 here on  this side notice that it has been saved in cache   so let's go ahead and serve that page again and  this time notice what happens is we get a miss   so this page this new user our nginx server  isn't serving this page from cache by default   and in actual fact if we refresh this page it  does then get served by cache it says hit here   so this type of behavior isn't going to be  desirable if you are thinking to set up nginx cash   per page rather than per user now  let me explain what's happening here   so the default setup here is potentially we want  to allow the user to send a request to the server   now the first time it the user does that it's  going to send a signal go back to the g unicorn   server and django's then going to process that  request obviously what we're trying to do here   by serving data from cache is that we only  want to do that process once if we're serving   multiple static pages potentially to multiple  users because it's going to be a lot quicker   for us to serve a web page from cache rather than  having to process that page multiple times and the   having to serve it from our database and so on um  so having it already in cache just to send back to   the browser for multiple users is maybe desirable  in your scenario so the current setup here then   ordered the default baseline configuration here  is that the first user is sending the request   it's been processed and then that's been stored  in cache and then gets returned to the user the   second time that individual user makes the same  request that information is then stored in cash   and return back to that user now the problem  we have here is that the next user comes along   and then request the same page but nginx does not  serve that page from cash directly it then makes a   request django processes it and then that goes  into cash and then basically what we have here   is we have a cash situation per user which  means that we cash based upon the user or   per user rather than for example per page so  potentially what we want to have is a setup   whereby a page say page one is cached initially  and then any other request from any other user   will then get served that page from cache  rather than it going through this process again   now for us to understand what's happening here  in django we need to understand two things   the vari header and also cache key creation and  let's start off by understanding what http headers   are the basics of http headers now generally  in our browser we type in a domain name and   then we send a http get request to a server and  that serves the resources back to our browser   now this http get request is typically a message  to the server a location which then the server is   allowed to is able to utilize and to serve the  correct resource back to the browser so when   we're sending messages from our browser to the  server http headers lets the client our browser   and the server pass additional information with  the http request or response so we can just think   of http headers as metadata additional data that  can be passed between the client and the server now if you press f12 in chrome or using safari  you can utilize the console there you can see if   we go over to a network here we've seen previously  that we have some additional information here so   we can go ahead and inspect not only the response  headers but also the request headers the requests   that we sent to the server and the the additional  metadata that we sent to the server so this is all   additional information that we're sending and  it's critical to understand this to understand   the behavior that we're experiencing with the  default setup here with the nginx cache and django   so if we drill down a little bit further here in  headers now there's a lot of information here but   we're not going to go into any more detail  here what we're going to be concentrating   on here is the vari setting here and you can  see that that vary here has been set to cookie so the question to start off then  is what exactly is the vari header   the vari header allows us to specify a  list of header names so the very header   um if we go back into our browser we can see in  our browser here the vary head is just specifying   another header option uh cookie uh so down  here you can see we have the other header   option cookie now this very uh setting could  include multiple uh different options but   essentially it's just pointing um just indicating  uh other headers that exist in our header   so as you mentioned the vary header allows us to  specify a list of header names and these values   uh or these headers can then be utilized by cache  tools such as the nginx cache to create cache keys   so this example here imagine this user is french  and they've got a browser and it's configured with   the french language by default so whenever we send  a http get request over some of the information in   the header will determine the fact that that user  is using french language by default so that's all   good and well but potentially we can use this vary  header to change the response from our server or   from our cache to determine what page to send back  or what resource to send back so the whole idea is   that our browser is sent across a request for a  web page and then we've sent in the vari header   we've sent accept language and which is referring  to the header which defines the the current   language of that browser for example so what's  happening here is our web server our nginx server   can read that very heady header um and because  it's in vary we're saying oh this is important so   the nginx server can have a look at this and then  utilize the then utilize this header information   in this case accept language to actually then  serve different web pages to this browser   so if you imagine someone else comes along  and maybe is using a the italian language   in their http request in their accept language  header they will have the italian um setting so   instead of your cache or your web server now  serving the french um website um it now sends uh   serves the italian and that basically then allows  us to maybe cache different pages because in our   cache we might want to save the french version  and we might want to serve and save the italian   version in cache so vari allows our web server  or our cache server to generate keys generate   individual cache pages for individual settings  that might be needed by different browsers   so let's just go back into our headers  here and we can see if we go down   to our headers we should be able to see the  the language header i've just pointed out um   okay except language and you can see here  by default um i'm set to e-n-g-b english so hopefully now we've established that the vari  header allows us to specify a list of header names   and these values can then be utilized by our  cache server to generate different pages or   cache different pages based upon these different  settings now let's convert that into our findings   about serving web pages with django notice here  that the vary has been set by django to cookie   so now we have the answer as to why django  and nginx was serving individual cached pages   to individual users rather than caching one page  and then using that to serve to multiple users so   what's happening here is that our user say user1  goes ahead and creates a request to serve page one   from django now that request gets sent across  and then django adds the cookie header in vary   and then serves that back over to nginx  now nginx reads um that response it then   looks at the vary header and then it utilizes  that information that's been set in the very   header to create a cache key so it then creates a  a cache key and that key key essentially matches   the request to the the data that's been cached so  it creates a cache key and it includes the cookie   now the reason why it concludes the cookie  information is because it's been told to   in the vary header um by django that was placed in  the header so it utilizes the url and the cookie   information now that cookie information at the  moment is essentially unique per user so this user   one has got this individual cookie information  and that's unique to that user so whenever this   cache is being created for that individual  page that's then going to create a unique   cache key that's going to be unique for that  individual user so when that user then goes ahead   and makes the same request again um the nginx  server matches the cache key with the information   from the header request and then it knows that  that user has already been to that page and   then it can then serve that information from cache  rather than it being served from the back end here   now the problem is when a new user comes along  and makes the same request the problem is here   that the cookie that they're provided is going to  be different from the first user so therefore when   nginx looks at the request from the second user  or the third or fourth user then it doesn't match   the cache key that's currently been stored in  nginx server and then it doesn't serve that cache   information back to that user it then goes ahead  and does the cycle again and makes a new cache   entry with this browser this user's cookie which  is slightly different and then the url again so   therefore when the second user then makes a second  request then nginx then utilizes and matches up   the cookie in the url with that particular user  and then serves that information back to that user so let's just go ahead and simulate this  problem again so inside the docker extension   here i'm just going to remove this container  the nginx container and i'm gonna go ahead and wait for that and then docker compose up  again so we bring up that container a new   instance of that container um and let me  go ahead and just access our web page again   so not found so this is in chrome on this  left-hand side here so we can see by going   over to network here we go to the first page  page one and this time we should receive   a miss so x proxy cache miss and then we reload  the page again it should now be stored in cache   and we get hit okay so page one has been cached  so let's go ahead and do the same thing over here   so this is um utilizing safari um  so that's gonna need for you to   access the development control  panel here go to the web inspector   um so we should receive the same type of  information um so let's go ahead and go to p1   so we can have a look at here the headers  here we get the x proxy cache miss so you can   see that this page one is stored in cache for  this user here in this browser um but because   like we explained earlier about the the um  setting here it's creating an individual uh   cache key that's individual for the  individual user so it's only caching per user   and not per page at the moment so if i refresh  this page again this time if we take a look here   we can see that we have cached this page for  this individual user says x proxy cache hit okay so just to double sure that everything  has been deleted and probably the quickest   way is just to remove the nginx container  again and we'll just rebuild that container   and we'll give that a couple seconds to close  down we just rebuild that again so we get a   fresh container right so let's go ahead now  and think about how to overcome this problem   so moving back over to nginx to the deconfort  configuration inside of our configuration   obviously at the moment what's  happening is nginx recognizes   the the vary header and then performs actions  based upon the settings that have been defined   so we can basically just tell our nginx  server just to ignore so let's go proxy cache proxy cache uh on a proxy ignore  sorry proxy ignore um headers headers   and then we can just define the header we want  to ignore in this case it's the vary header   so simply put now the nginx server  isn't going to be utilizing the very   information to generate the cache key  so let's go ahead and actually just uh   remove our nginx server again we'll just  start this up again and with this new setting   okay right so with that in place let's do our  experiment again so we start with two fresh   windows one chrome one safari and let's go ahead  and just simulate this so we go back onto our   page here uh we'll open up the console let's go to  page one so we're expecting the first page to miss   um yep so we've got x proxy cache miss  here and then it then gets served from cash   so we now have x proxy cash hit right  so let's do the same thing now this is   a fresh incredito private window here in  safari so let's just run uh this again   so let's just open up the development tools  the web expector so this time we're expecting   because nginx cache isn't utilizing the vary  header settings to generate the cache key   what we should have now is this page is being  stored in cash so anyone who requests this page   now because it's been stored in cash should get it  directly from cash so let's go ahead and go for p1   and what we're hoping for is to straight away it  coming from cache and you can see here we get the   x proxy cache hit straight away which  is indicating it is being directly um   served from cache excellent so now what we have  is a setup where nginx is serving individual   web pages from cache and that isn't determined  or isn't dependent upon individual users it's   going to be for a site-wide basis any user now  that access that page will be served from cache   so hopefully what this little exercise  has provided it's given you this idea   or a deeper understanding of how this cache  can be configured for different scenarios here   because we now know that cache can be configured  per individual user and it can now also be   configured on like a site-wide or or in a global  way and that's where it gets a little bit more   interesting because potentially part of your  site you might want to cache or part of your   site or different resources you don't want to  cache maybe because your page is very dynamic   you don't want to cache that particular  page because of that maybe you want to   have kind of site-wide static pages that are  cached but other dynamic pages aren't caching   we can start to control that utilizing um the  vary header uh potentially and other headers   uh so for example let's just go for a simple  example here whereby we're going to cache pages   um if the user isn't logged in because we're going  to make the assumption that if a user isn't logged   in they're just going to our webpage they're  browsing our web pages it's all static and we make   the assumption that if a user is logged in some  of those pages potentially are very dynamic and   we don't want to potentially cache it at this area  here so let's look at how we can set up in django   so let's actually log in as a django user uh  so we'll go to admin here um i don't know if   i've set up a an admin user yet no okay so we  haven't set up an admin user so let's just go   back into the project um it's a little bit of uh  a faff at this point actually let's go into the um   let's go into docker here uh now we may as well  set this up so let's go back into our project   and apologize there's a little bit of setup  here that we're going to need to go through   so we're going to need to make a virtual  environment for this so let's go ahead and do that so create a virtual environment and then just need  to activate that virtual environment depending   on whether you're on windows or mac it'd be  slightly different here um source need source okay so that's activated let's  just uh pip install uh django and then we want to basically make a django user  so we just need to cd into django the django   folder here where our project is and then we go  ahead and use python and manage pi create new user   now we will get a problem here that's not a  problem a loud host because we're utilizing   environment variables by default here or at least  in this environment we can't do that um with this   setup at least so let's go into our django demo  go to settings here and a loud host what we'll do   is we'll just add a default just allow us to get  started so default equals like we got here default   equals and let's just put our local loopback  address so that should allow us now to run create   create cpus apologies create secret user uh and   then let's go for admin no email password is just  admin and then y so we just created a new user   so let's go back into the browser hopefully  at this point we can go ahead and log in site cannot be accessed  looks like there's a problem   it looks like all our containers are down no  problem um let's just restart the containers okay so the containers have restarted so let's  just go back and to log in again so admin admin   so now we've logged in let's just expand this  so let's have a look at um our headers here   so if we can see any additional information so if we look through the headers  what's happened when we log in django   uh creates a new cookie for the session id so  what's happening here is that you logged in and   through the session id that uniquely identifies  you or helps django uniquely identify you   as someone who is actually logged in so  all we have here is a cookie session id   with that information in hand we can  then go back into our configuration here   and we can set for example proxy uh cache  bypass and then we can basically tell enginext   if a user is logged in or has sorry if the user  has this particular information then basically we   want to bypass cache and just request it from the  server and that's obviously the cookie session id   so that session id has been added that  cookie session id has been added to   anyone who's logged in so basically now  anyone who's logged in um the cache is   going to be bypassed and then it's going to be  served directly from the server the information   so let's go ahead and test this new setting  out um so i'll just go into the server   and i will just restart the server that will  take up the configuration so let's go back into   our browser now we are logged in and we should  still be logged in yet refresh so let's go into   our admin page sorry let's go into our page  here remember we should be serving that from   cache but if we go down here you can see here it  says x proxy cache bypass because we're logged in   we're bypassing the cache and that's the behavior  that we're experiencing here so we're not getting   this information from cache if we're logged in  so let's just log out and see if that's worked and then we go back into the page and  you can see this time we get a hit   because the page has been cached and we're  not logged in so if you're just thinking about   building a static web page a few different pages  and you want to serve those some of those pages   from cache using nginx then you've got the setup  now to do that and you can see that for logged   in users maybe you're utilizing some more dynamic  page and you don't want to serve those pages from   cache in which case you now know how to bypass  cash for logged in users the final section of   this tutorial we're going to discuss how to manage  and control cash from a django project so not only   can we configure cache control from nginx we  can do this also within django because you may   have ultimately a setup where there are multiple  cache aspects of your setup it can be better or it   can be more preferable to configure cache control  actually within your django project so let's take   a look at some of the basic settings that django  provides us to manage the vary header and cache   control so for us to be able to do this we're  going to have to create a new app here so back   in back in our terminal here we are inside of this  project i believe yep yep so let's go ahead and create start a new app and let's  go to call this app demo app and then we go into django and then we just  go ahead and register this new app demo app   okay so from there we now have our demo app so  we now have um our views et cetera so in our urls   we're just going to make a change here um so at  the moment we're just using generic template views   to serve the page so you just want to swap  that over so our new django app is serving   that page right so to do that um let's just  go ahead and from demo app let's import   views it doesn't exist yet but it will do shortly  and then what we do is we just serve page one from   our new django app views dot home page we create  a new view called home page and that sets that up   so that's in demo urls so now we're going to serve  this url from our new app so in our new app here   let's go to our views uh so just a simple view to  get us started here um so because it's home page just standard stuff here request and then  we go for a return so return render and then   pass back in the request and then  also p1 dot the actual template   okay so that's the template being passed back   so we'll go ahead and inside of our demo app  create a new folder um we'll call that templates   and then inside of here i reckon we go ahead  and actually i don't think we need to do that templates have already been configured  on this server for that folder   it's been served from so we should be good  to go there so here we are then back in the   django documentation would you believe  it there is an entry for vari headers   and we can control and manage um what is  returned in the vari header within our django   project so if we do have some specific setups  whereby we want to cache in certain instances   we can then go ahead and define our very headers  and we can do that based upon the view for example   so take this example uh so we're bringing um  views decorators the vari decorator and what   we can do here is we can utilize this decorator  and to actually define per view for example   what we want to return in the very configuration  so headers and then let's go for accept language   from our example so we had except language so  what we're going to do now is add that to our   vary header so let's just see this in action so  let's go ahead and rebuild so i'm going to do a and then build and let's get back into the browser i'm  just going to re refresh the page here   and then have a look at the very settings um so at  the moment in actual fact we're just returning the   cookie so what we're expecting to see here um is  now the accept language in addition to the cookie   so just try and keep it as simple as  possible i'm going to just remove everything   um from docker and just start again uh rebuild  again just to double check everything is working   from our new configuration uh okay so we go  ahead and we just remove absolutely everything   of course we don't need to do that um but it  just means that um there's kind of a level   playing field for everyone uh avoid any potential  errors so let's just go back and run up again so with that done let's go ahead and just refresh  our page again and let's go ahead and have a look   so this time you can see that we now have vary  and we're accepting the language and cookie   so clearly what we've done now is we've  added some additional information into vari   and potentially that can be utilized in  the the levels or different areas of cache   to create different configurations so i apologize  it's hard to give you any concrete examples here   i'm just trying to explore and show what is  possible for you to then go off and explore   and think about potentially utilizing that  in your project in the django documentation   there are a few different ways of working with  this and we can also utilize more directly the   um the cache utilities and from here we can  set up a different type of a way of working   adding the the very information um so we could  work with something like this for example   so actually we've completely messed that up um  produce let's just return that there we go so   what we're doing here then we brought in the patch  very headers so what we're doing we're getting the   response and then we're going ahead and we're  just adding some additional information here so   within the patch very headers we're adding the in  this case the user agent into the very headers and   then returning the response so just a different  way of working a more manual way of working   so while we're talking about the vari header  closely by here in the documentation is caching   so here we have in addition to adding different  headers we also have the options to kind of   manage cache um more directly here using  cache control so the cache control header   can be used to control how caching is performed  and again remember caching isn't just on in this   case our nginx server there may have be different  levels of caching throughout your infrastructure   before it hits your server so it may be  important to you that you're able to define   different cache settings based upon different  urls or on different views delve in deeper into   the documentation what we have here is the view  decorators cache and that gives us cache control   so from here we've got a number of different  options so let's go ahead and use this decorator   so this is going to be cache control and then we  can then define some different parameters here   so the first parameter we can set is public or  private and this essentially allows or forbids   caching in public caches in this case we we have  a reverse reverse proxy server so we can directly   tell our caching servers to cache our view or  not utilizing uh private and public so i can just   call this uh private and then add that to true so  basically i'm saying that we're not going to cache   this view two other parameters that we can pass  is no cache which disables caching that makes a   client to perform a request to the original server  and then we also have max age parameter which   essentially says after this time defined in  seconds cache is considered stale so let's just go   ahead and try this setting here uh so i'll  go ahead and we'll just rebuild this server   so just remove the the web server  let's go ahead and rebuild that okay so let's give this a go so p2 p2  should be um casual so x cache miss   refresh and you can see that we are then  getting hit so pt or page two is being cached   right so page one then so we've denied cache  um here so you can see that oh actually   um x proxy cache is hit here so potentially um  we're still serving it from cache it hasn't been   updated so let's try that and so let's just uh for  speed let's just go ahead and remove the nginx um to remove these containers and let me go ahead and  go ahead and just rebuild that again so up build   just rebuild those containers let's try that  out again so everything comes up and it's on   so let's just go ahead and refresh p1   and then this time you can see we have  a miss on the x proxy cache and then p1 is again we have the cache miss so it looks like  this time we've now configured this correctly   um because we're not actually catching  this page and then let's go for p2 so we can see here we miss and then we hit so cache is working on page  two but not page one so that goes in line   with what we've set up here in this cache  control setting hopefully that's given you a   grounding and you're now confident in starting  to think about utilizing nginx cache to serve   django web pages thank you very much for listening  and i hope to see you in the next tutorial

Channel: Very Academy

Views: 4,223

Keywords: Nginx, django, nginx cache, django cache, vary header, django cache directives

Id: 1BwPU17IIVo

Length: 46min 47sec (2807 seconds)

Published: Fri May 13 2022