Send Varied Default with airSlate SignNow

Send varied default

Haight so my name is Andrew I work firstly and I am unnaturally obsessed with the very header and over the next 30 minutes I hope to make you unnaturally obsessed with a very header - when I did this in New York I called it the very header and the future of cash variation at the edge and only about five people came so I decided I needed a more exciting title it seems to have worked so I'm very happy about that so to talk about the very header I need to dive into a little bit of history and to put give us a bit of historical context not this old this old in 1997 HTTP 1.1 was standardized and with it we got something called content negotiation content negotiation is in principle a really amazing idea you could talk to your bank and say I'd like my statement please and the bank would by default giving you your statements a webpage but what if you could send an extra header saying actually I'd like that statement as a spreadsheet and on the same URL you get the same data but in a different format this is amazing we can browse the web in any format we like this is incredible mmm except it doesn't quite work because a lot of organizations that have the most useful content that we would most usefully like to see in lots of different formats just don't make it available any other formats so you send your accept header saying hello Bank accept text CSV and they say so we don't actually get what we want so unfortunately content negotiation didn't really work so is content negotiation debt well it is for format format content negotiation so the accept header really doesn't work but it works for other things so I like to say the original idea of content negotiation is dead but it lives on for other use cases and there are more use cases actually appearing all the time so one of those came up when I was in Japan last year working with Nikkei and their website Nikkei calm is in Japanese and I don't speak Japanese so when I open my laptop which is localized in English and I go to their website I get this pop-up that advertises their english-language publication but when my Japanese colleagues go to the website they don't get this pop-up so that's clever the website has identified that I have different language settings to someone else and he's offering me a different experience so how does it do this well every time your browser makes a request for a page from a server it sends a whole slew of information one of those headers is the accept header that we've already covered and doesn't really do anything another one is the accept language header which tells the server which languages you speak so in this case I'm saying that I would like the response in English either Eng Bo in u.s. failing that any variant of English of which actually there are more than 40 I didn't realize so we have the same URL for two different users and different responses and this sounds fine until you insert caching into the middle of that exchange so users typically don't interact directly with servers for large sites they go through a content delivery network such as fastly other CD ends are available and that cache will store responses from the origin server and use those to satisfy feature requests from other users so this means that if we have someone who speaks Japanese who requests a page and we fetch it from the origin server we'll get a Japanese one and then later someone else will come along who doesn't speak Japanese and they will be unimpressed so we need to solve this problem so a typical way of solving this is just to make this page not cacheable your logic is this is a page that varies for different users we can't predict which kind of user is going to come along there's no difference in the URL therefore we can't cash it and this is a shame because this means that one of the most popular high-traffic pages on your website is going to go all the way back to your origin server every time so a better solution is this where we can say yeah it's fine to go ahead and cache this page as long as you take notice of the accept language header that is on the request so now everyone's happy we can store two different variations of this content on the same URL but with different except language settings so how does this actually work well when a request comes in we generate a cache key most caches will use the host name in this case example com the path slash home some of them will add the method like get or post as well and that will produce a key which we can use to look up whether we've got that object in the cache so let's say we don't we've got no responses in the cache so we send this request to the origin server which then responds with an object that includes the very except language so now we need to do another step we need to compute a secondary key because we know that this response is not usable for every possible request for this URL it's only usable for a subset of those requests and we need to figure out what subset so we generate a very key based on looking at the request that came in that triggered this response and copying from that request the important nugget of information which in this case is en so then we store against the cache object the cache key the very rule which is accept language and the key for that rule which is en so then when we get another request this time for accept language J we compute the cache key and the important thing is the cache key is still the algorithm for generating the cache key is still the same so we're going to find a hit in the cache but this item we found in the cache is not immediately usable because it has very rules so we have to we have to interpret those very rules and check whether this object is actually usable for this request in this case it isn't because the accept language on the request doesn't match the very key on the stored asset so we would send this request to the back end as well and so on and so forth let's imagine we have three objects in the cache now all for the same URL but with different very values and notice that for each one of these we are storing the very header and in each case it's the same it says language doesn't have to it makes sense conceptually for us to imagine that where we have variations all the variations are variations of the same thing like language but actually very doesn't require this we can specify that different variations are actually based on different rules and that means they can potentially crossover in confusing ways the other problem we have is that when we vary on things we can have a lot of possibilities so I sampled some data going through some of our pops our data centers and I found that there were over 5,000 unique values for accept language over a 10-minute period in all three of these data centers that I looked at you can see there's some geographic clustering so in Tokyo it's much more likely that the user will want Japanese in Washington is much more likely they want English I actually sampled Frankfurt in the middle of the night in Europe so the most popular language in Frankfurt is also English at that time of day so we need to do something to make very more useful and the first thing is to normalize or normalize with as read as they would say in u.s. it amuses me that there's two different spellings of the word normalize so on fastly we have a function called accept language lookup and this is a proprietary function but I am going to look at standard space ways of doing this later on so with this we can type in the input data that we got from the request and also give it a list of languages that the backend supports and then get out one single value that is one of those six languages that we support and so this reduces a granularity of 5,000 down to a maximum of six and this brings back our cache efficiency we now get a decent cache hit ratio now one of the problems that we have with very that limits its usefulness is that we can only really vary on headers that are there we can't vary on things that are not in the request but are things that we nevertheless know about the user or about the environment so typical things that we vary on our accept which we we've established doesn't really work except language which works pretty well but people don't really use it enough and accept-encoding which is whether your browser supports gzip or broccoli or deflate what about more useful things like whether the users logs in or what kind of role the user has or what country they're from these are things that are not just added to the request by the browser but we can add them if we have the ability to create headers at the cache layer so imagine that you have all of this information embedded in a cookie but you don't want a very on cookie because basically every cookie is different right it's gonna have your Google analytic stuff in it and it's gonna change and every request it's gonna be useless so what we really want to do is distill out of this cookie some nugget of information which is the thing that we actually use to determine what response to serve so it might be that our server actually only has two possible responses one for free users and one for paid users and the fact of whether this user is free or paid is buried in this cookie somewhere but we need to extract it so that we can create only two variations so if you have the ability at your edge cache to scripts the conversion of this cookie into separate headers then you can very on just that one header that you need so previously we could vary on cookie now some caches are actually hard-coded to not cache things that have very cookie just because it's so pointless to try and do it and after we're varying on something which only has three or four variations so it's very effective now of course we can't send this very header to the browser because the browser was not aware of this header it didn't send it so by the time we get to the browser we'll need to have converted this very head of back into very cookie or just a no cache cache control header so earlier on I Ted I said that it was possible for different variations of the same URL to actually define the way that they vary in different ways which is very confusing and that when that happens it usually causes problems it can also actually be quite useful so let's look at a way it can be bad in a way that it can be good so one way that it can be bad is if you create accidentally variations that cross over into the same space so in this one case we have a request that does not specify an accept language so we think okay well you didn't specify an accept language so I can't vary in it so we won't include a very header in the response but what we're actually saying there is that this response is valid for literally any request and it doesn't matter what the value of accept languages so then if we have a second request that specifies an accept language and we respond with a very accept language we've now created a variant which is good for the same kind of request as the first response so we have two responses that are actually both valid for a particular kind of request and that's really bad news because the different different cash implementations may offer implementation specific conclusions from that so you may some caches may give you one variation some caches may give you another one so the answer here is that we need to vary accept language on both of these responses and in the first case what we're actually saying is that this response is only good for requests that don't have an accept language or have an accept language of an empty string so in general always include the very header in the response even if the thing you're varying on is not present in the request because then you you you you don't cross over in the sort of if you imagine a Venn diagram of your responses they don't intersect but what about this kind of situation so let's imagine we're varying on multiple headers and if you multiply together the number of possible values of each of these headers we've got two values on one we've got four values on the other so that's a total of eight possible variations one of them's for a/b testing and one of them is for whether the user is signed in or not so imagine that we only do a/b testing on users that are signed in so that means that all of the variations that we're creating for anonymous users are going to be the same but the cash doesn't know that so it is going to store separate variations and if it doesn't have one of them then it might create an unnecessary request to the origin so what if in our response we vary on different things depending on what the value of the headers is so for user that's anonymous will vary just on their user role so we care about the fact that they're anonymous we don't care about what test bucket they're in if they're a subscriber will vary on the user role because we care that they are a subscriber and we also care what test bucket they're in so will vary on that too and this creates a sort of asymmetric tree but still importantly it's completely deterministic there's no crossover in what possible requests these responses can satisfy now I should carry out this by saying that this is somewhat implementation-specific the faster the implementation of very supports this you might find some caches that have optimized their very algorithm to the point where this doesn't work I haven't found one yet but I imagine it's a possibility so this is all very interesting and this is what happens in edge caches what happens in the browser it's the same right most all caches behave the same you would think well first of all browsers actually only store one variation so all of this talk of different numbers of variations and how we match the variations and how we iterate over the variations all has no bearing on how the browser works at all browsers implementations of vary are typically much much simplified and they use the very header as a validator so all they use it for is to confirm whether or not they can use the thing that they've cached not to cache multiple variations and we can prove this wit quick test case for requests for the same URL in sequence the first one seats the cache the second one is identical to the first one so it is returned from the cache the third one changes the value of a header that we are varying on so that will miss the cache and the fourth one goes back to the same settings we had for the first two so you would think that in a cache that stores multiple variations that would be a hit but it's not in the browser because the first one that we cached has already been evicted by the second variation that we cached so we have to be aware that that behavior is very different between what so called shared caches and private caches except browsers actually have six caches so it's this is only true for the HTTP cache the one that we most commonly think of and interact with when we're talking about browser caching but there are lots so we have the image cache the pre loaded cache the serviceworker cache API the HTTP cache and also the HTTP to push cache as well as the edge cache and we have to consider how each one of these caches interprets and processes varying rules and because it turns out that they're all somewhat different so let's look at serviceworker when serviceworker spec was created the author's looks at the way very works in the HTTP cache and they thought this is broken this is a bug it shouldn't work like this it should work the same as shared caches so they suspect the serviceworker to actually work the same as a CDN would and to store multiple variations and that's great and that's the way Firefox works unfortunately chrome doesn't work like this and the service work in chrome acts in the same way as the HTTP cache so it will store any one variation and I've done a test case to demonstrate this which you see the URL for the end of slides another wrinkle is 304 not modified response and this is actually true both in browsers and on shared caches when we have cached something that has a validator like an e tag or a last modified header that means when that object becomes stale we don't need to make a fresh request to the origin we can make a conditional request a conditional get they includes an if not modified or an if none match header and then the origin has the opportunity to respond with a 304 response saying you know what it's okay to continue to use the object you still have in the cache what we don't think of so much is the fact that that 304 response modifies the object that we have in the - it'll modify in an in a fairly obvious and sensible way to update the TTL because it makes sense that if we receive a 304 response with a cache control header on it that we renew the object we have in the cache for the duration of the cache control max-age that we got on the 304 response so we could have an object that was originally good for 30 seconds after 30 seconds we make a conditional get and then the services this is now good for a minute so we update the TTL and the object that we originally cached is now good for another minute but there are other headers that we can transfer from a 304 response onto an already cached object and one of those is the very header so you can change what an object that you have in cache is actually valid for without sending the client a new one and this is very confusing because you can actually make the object that's already in the cache not valid for the request that originally generated it which is very confusing in fact at first glance you might think that a 304 response that includes a very header might not be valid for the requests that actually generated the 304 response which would leave you in a very awkward position but the spec is quite clear on this and the browser should use the response in that scenario but it might then not use it if it generated a conditional request in the future that was identical to the first one that generated the object in the first place confusing the conclusion is if you are going to have objects that are that are possible to conditionally revalidate then either don't use very at all or make sure that on your 304 responses the very value is always the same as it was when you serve the object in the first place so let's move on to HDTV to push what does the situation look like here well this is complicated because push is about service sending you things that you haven't asked for so there is no request so it feels like very probably wouldn't work in this situation but actually it is tightly possible for it to work because in a push a server sends a push promise as well as the pushed object and so it is essentially telling you if you were to make a request that looks like this then this response would be a valid response to it so in theory we could apply very rules in practice none of the browser's actually do so if you if you push something browsers will typically match it purely by your app and all the very rules will be completely ignored and in fact this isn't really bothering very many people at the moment because in a recent version of Firefox stable missile a broke push entirely for a whole stable version of Firefox and no one seems to have really bothered noticing so I don't think a lot of people are relying on HTTP to push at the moment and it is now fixed so oh and the conclusion on this is don't use very on pushed resources because it won't work and if in the future browsers ship support for very on pushed resources the behavior of your app might change in unpredictable way or a way that you haven't tested or you are not able to currently test so right now don't use very on the push so let's look at the future and why ferry is now more exciting than it used to be so first of all we have proposals to improve and replace the very header with things that are more useful like key which is a proposal that my colleague Mark Nottingham has been kicking around for a while so he is more useful than very because and now allows us to be more precise about what we're varying on one of the reasons that very cookie whose never was never something that would ever work is because the cookie header includes all your cookies so you know if you've got any kind of analytics tool that's changing a cookie value on every request then very cookie will will basically kill off your caching ability completely but you might have one or two cookies that are actually very granular like the role or the login state of the user so if you could very on just that cookie then you'd be able to do useful things so key allows us to to do that to be more specific about what part of the header we are varying on another thing that has been kind of rolling out for a while is client hints this is fully supported in crime and it's it's gradually rolling out to other browsers and client hints gives us new headers that we can vary on or we can usefully vary on so for example the the client hint headers that are supported at the moment are the device pixel ratio the width of the screen the width of the viewport and whether the user has enabled save data these are things that you are likely to want to vary on right because they are going to trigger the server to return a different kind of response and some of them are awkward like reeport width and width these are values that are quite granular you could imagine having hundreds of possible values coming through in requests so key is actually useful to us here as well because one of the other features that kee provides is division's so you can say I want to vary on viewport width but in divisions of 50 so what this will do is it will take it it will assume that the value of this header is numeric it will divide it by 50 and round it down to the nearest integer and that will be the value that actually ends up being varied on and key also includes a couple of other little kind of micro algorithms that you can apply to headers to usefully reduce their granularity so this is a this is a the standardization process reacting to this need to normalize like I was talking earlier about normalizing the data that's coming through in about translating cookies into private headers this is a solution to that that standards-based so you wouldn't need the ability to script your CDN anymore if you can do this a sort of partner to key is the variant spec also by Mark where he allows us to in the key header define the semantics of a particular header variance actually bakes in the complex semantics of existing well-known HTTP headers into the spec so it gives caches the ability to understand much more intelligently what they're actually looking at when they see the data so for example with a variance header we can say for content language and content coding our server supports these variations and this means if I come to the cache with a very complex request like an accept language header that lists five languages that I speak and I prefer this one and then this one and then if not that one then this one and you know I prefer this variation of English versus this one caches traditionally have not understood any of this they just treat it as a string whereas with the variants spec we could give cash is much more intelligence to semantically understand what that means and then match it against what they have so a request comes in saying I would like these languages in this order of preference we know that the server only supports a subset of those and we also know what objects we already have in the cache so we can make an intelligent decision about which of those objects we can use potentially to respond to this request even if the requests that generated that object in the cache didn't have exactly the same except language header so again it's about reducing the granularity of the variations storing fewer variants and giving you a much higher chance of matching something that's already in the cache so we can take proprietary solutions like fast these accept language lookup and kill those off because this is again a standard solution that would work everywhere that supported the variants header so to close up a few questions for you two to take away maybe you're making unnecessary requests to your origin maybe consider looking at responses that you are sending back from your origin that are not cashable where you are setting no cash no store private etc on your responses is there a possibility that you could be caching this response if you were able to use very do you have use cases for normalizing other fields like could you could you make use of key if you can make use of key then follow along with the development of that and see and you'll be able to see when it starts to be supported by browsers have you thought about using private headers in the meantime you know whilst when you because we don't yet have support for key does your CDN support breaking out complex headers into separate headers that you can then vary on the entire header using the the traditional very header should we standardize the normalization of well-known headers like accept language and accept encoding if we should then follow along the variant spec which is very very early alpha at the moment but mark is iterating it quite quickly and a final question that's been rattling around my head is at the moment we can't actually edit or customize in any way the headers that the browser sends when doing page navigations we can edit the headers when we do a JavaScript fetch we can add whatever head is we want subject to some rules but we can't do anything about the headers that are sent when a user clicks a link would that be useful should we have that ability I'm interested to know what people think about that so I'm also happy to take your questions as well if you have any and I leave you with the thought that everyone should aim to be variable at all times much yes we've got the lots of time for questions actually so does anyone have any questions any takers I dunno about transparent comes in negotiation but I haven't I can't remember exactly how it works remind me where what spec that was yeah it rings a bell but I I I have no real memory of that so I've no opinion really I think the the general answer in relation to having things stick when people try and standardize them is the extensible web process is now a lot more pragmatic than it used to be the standards process used to be very disconnected from the practical reality of the way people use the web and now it's much more connected and it's much more fast it's much faster to iterate so you'll find that things are trials via say Google's origin trials program which is a really good way of testing out new features on the web without baking them in in a way that is becomes essential that we continue to support them you know we've had many instances in the past where ship things on the web which later turned out to be not the perfect design but we had to keep them exactly that way because people started to rely on them and so then there was this movement towards make it perfect before we ship it but then you know we have situations where we never something never ships because you know enthusiasm for it dies out and what-have-you and I think the new approach to trying things out behind flags and origin trials is a really good approach to testing the water with new features so I'm hoping to see origin trials for some of this stuff soon any other questions I gotta show you a question cool it's very pungent arrange this no no no it's very possibly the most complicated header to handle the whole HDPE oh I'm sure it's not no I can't think of another one but I like cookies probably quite complicated the way that it's that cookie in mmm no you're probably right it probably is very actually any other question yeah Michael I don't it was my it was my understanding that it is being implemented and there is intent to implement on the part of most browsers and Patricks nodding at me so I think this is true and what's more there are other standards that are now building on client hints so in the tag we're currently reviewing device memory which is an extension to client hints so I showed before client hints that are part of the client hints spec but the client hints is just is it basically a framework for adding additional useful headers from the client and the spec defined the four first ones but it anticipated there would be more and so we're now starting to see additional client hint headers coming out as new specs so I think we're pretty much as a as a platform wedded to client hints at this point there's still some argument over things like except CH which is a header that the server sends to say I'm interested in knowing this information which is unusual because mostly the information that you very unlike except except encoding except language the browser just sends this stuff anyway and most servers ignore it but you don't ask for it you just get it anyway and client hints actually has an opt-in mechanism so some people are saying well the values for the client hint headers are actually fairly small they're usually just numbers why don't we just send them anyway you not have this inconsistency between client hints and other variable headers but that's pretty much the only debate going on I think at the moment I think the the actual feature is pretty much sold I don't know timetables for other browsers implementing yes it's time for another couple of questions if there are many okay that's all it drink no anyone all right so let's thank our speaker again thank you very much [Applause]