WEBVTT 00:00.360 --> 00:03.070 So welcome back to the Knowledge Portal Video series. 00:03.090 --> 00:09.270 So we have finally reached the stage where we can actually talk about the content negotiation in the 00:09.270 --> 00:10.560 Http protocol. 00:10.800 --> 00:13.530 So let's explore on what it is. 00:15.560 --> 00:21.880 So let's take an example where this is a client or a web browser, and this is a video streaming server, 00:21.890 --> 00:23.870 something similar to YouTube. 00:24.350 --> 00:31.640 Now, there are a lot of videos in this video streaming server, and each video is associated with three 00:31.640 --> 00:32.450 qualities. 00:32.480 --> 00:36.260 One is for RTP, one is 720p and one is 1080p. 00:37.920 --> 00:45.660 Now, whenever a client requests come to this particular server asking for a video, how will a video 00:45.660 --> 00:49.410 server determine on what is the quality of the video? 00:49.680 --> 00:51.750 It has to serve to the client. 00:52.710 --> 00:57.120 So one of the techniques is based on the user agent string. 00:57.450 --> 01:04.290 So it was assumed that the mobile clients always had a slower connection than a typical broadband. 01:04.800 --> 01:12.690 So whenever a video streaming server used to get a request with a user agent based on a mobile, then 01:12.690 --> 01:15.220 they tried to serve the lowest quality. 01:15.240 --> 01:19.920 So in this case, the quality that would be served would be typically for ATP. 01:22.580 --> 01:29.420 However, if a user region is based on a desktop browser, then the video streaming server can actually 01:29.450 --> 01:33.890 send video based on 720 or 1080p quality. 01:34.190 --> 01:36.020 So that really depends on. 01:36.860 --> 01:39.650 What algorithm the video streaming server uses. 01:42.030 --> 01:42.930 So. 01:44.130 --> 01:51.660 One of the ways in which a video streaming server can determine the quality that it has to serve is 01:51.660 --> 01:53.490 based on the client itself. 01:53.580 --> 02:02.430 So client, along with the video URL, will also specify on what is the quality of video that it wants 02:02.430 --> 02:03.060 to be served. 02:03.720 --> 02:10.320 So in this example, if you see the client is saying that I want to watch a documentary, preferred 02:10.320 --> 02:14.460 version is 1080p 720p is less preferred. 02:14.940 --> 02:23.790 So that means the client is willing to accept 720p however it wants to watch video based on the 1080p 02:23.820 --> 02:24.540 quality. 02:25.230 --> 02:31.930 So here there is no mention of four ATP, so client would not like to watch A4P based quality. 02:31.980 --> 02:36.450 So now it becomes easier for a video streaming server to determine that. 02:36.450 --> 02:40.920 What is the quality of the video that it would like to serve to the client? 02:42.240 --> 02:50.340 And this is the preferred version, because generally nowadays even mobile phones are starting to have 02:50.340 --> 02:51.840 a 4G base network. 02:51.840 --> 02:54.660 So even they have a very fast Internet connection. 02:54.900 --> 03:03.030 So the way in which a server can determine on what is the type of content that it wants to serve is 03:03.030 --> 03:08.550 based on the relative quality factor, which Http protocol provides. 03:11.310 --> 03:15.990 Now, the relative quality factor B is based on the Q parameter scale. 03:16.290 --> 03:20.850 So Q parameter basically ranges from 0 to 1. 03:20.880 --> 03:22.590 Zero means least preferred. 03:22.590 --> 03:27.480 Or I can also say not preferred, and one means most preferred. 03:28.910 --> 03:31.340 So if we take an example of the. 03:33.630 --> 03:40.830 The one that we have already discussed over here to the parameter scale, we can determine that ten 03:40.830 --> 03:44.070 ATP would be associated with one value. 03:44.070 --> 03:46.740 So one means most preferred. 03:47.100 --> 03:52.740 However, 720p is less preferred, so it can come somewhere in between. 03:52.740 --> 03:57.060 So we can assume it can be it can have a score of 0.5. 03:57.090 --> 03:58.740 That means less preferred. 04:00.580 --> 04:03.040 So let's take an example. 04:03.160 --> 04:05.860 Then it will become much more clearer. 04:06.970 --> 04:16.900 So there is a the first example is related to website which has multi-language based content. 04:17.080 --> 04:24.520 So a browser in the Excel language header is saying that it prefers the. 04:26.150 --> 04:29.630 In GB, which is British English and Ian as well. 04:29.870 --> 04:35.240 Now notice that the language is associated with a Q parameter. 04:35.360 --> 04:42.410 So the Q parameter is basically the one that we were talking about here, which ranges from 0 to 1. 04:42.440 --> 04:47.060 Zero means least preferred or not preferred, and one means most preferred. 04:49.160 --> 04:56.690 So if there is no parameter associated here, that means that it defaults to one. 04:58.410 --> 05:02.910 So as there is no parameter associated with DIA, a dia is Danish. 05:03.000 --> 05:06.360 That means DIA is associated with parameter one. 05:06.840 --> 05:15.120 So if we translate this then the client browser is preferring Danish language. 05:16.780 --> 05:17.710 Of content. 05:17.710 --> 05:23.400 If Danish language of content is not there, then it is even ready to accept British English. 05:23.410 --> 05:32.560 So the second preference is British English with 0.8 parameter score and the third is 0.7, which is 05:32.560 --> 05:33.190 English. 05:33.190 --> 05:38.830 So if we translate it, then it comes to I prefer Danish language of contents. 05:38.860 --> 05:43.180 If Danish language is not available, then even British. 05:43.570 --> 05:46.180 British English is also okay. 05:46.570 --> 05:52.180 If British English is also not available, then you can even serve me normal English contents. 05:53.880 --> 05:56.670 And this is how the Q parameter works. 05:58.330 --> 06:01.330 One more example over here is that. 06:02.520 --> 06:02.690 It. 06:02.970 --> 06:08.050 The client is willing to accept page which is based on text slash HTML. 06:08.070 --> 06:09.390 So these are the mime types. 06:09.390 --> 06:15.630 We already discussed the mime types, so as there are no parameter associated over here, it means that 06:15.630 --> 06:18.540 all of these are associated with default value one. 06:19.400 --> 06:24.740 So here for application slash XML, the Q parameter is 0.9. 06:24.740 --> 06:29.660 So this is the second preference and the second preference is not available. 06:29.660 --> 06:33.530 Then for any other the Q parameter is 0.8. 06:33.770 --> 06:40.910 So this is how a client browser can tell to a server on what are its own preferences. 06:41.000 --> 06:46.850 And this is why it is called as content negotiation, because there is a negotiation of content that 06:46.850 --> 06:47.690 takes place. 06:49.390 --> 06:51.910 So as we have already seen, the. 06:52.740 --> 06:54.570 Basics of content negotiation. 06:54.570 --> 06:56.640 Let's open up Wireshark and see. 06:56.670 --> 06:58.920 On what exactly happens in the background. 07:01.300 --> 07:04.780 So I'll start my wireshark and. 07:08.080 --> 07:15.850 Along with that, let's open our Internet Explorer and let's go to example.com and go to example.com, 07:15.850 --> 07:18.730 slash my website dot HTML. 07:20.530 --> 07:25.150 Okay, So this is a content and this is a image file that has come. 07:25.630 --> 07:29.200 So if I stop the packet capture. 07:31.240 --> 07:33.160 Let's go to. 07:34.070 --> 07:35.150 Get my website. 07:35.150 --> 07:37.910 So this is the stream and let's follow the stream. 07:38.920 --> 07:39.430 Okay. 07:42.350 --> 07:45.740 So let me show you. 07:47.860 --> 07:56.710 If we look over here in the image source, when the server is making a get request for my Z dot PNG 07:57.580 --> 08:01.180 in the accept header, there is a. 08:02.190 --> 08:04.860 The Q parameter is associated. 08:04.860 --> 08:13.140 So if we see over here for image slash PNG, as there is no Q parameter, it means it defaults to one. 08:13.560 --> 08:17.280 Even for the second mime type, it defaults to one. 08:17.370 --> 08:26.580 However, for any other mime type, say image slash gif or image slash jpeg, etcetera, the q parameter 08:26.580 --> 08:28.590 associated is 0.8. 08:29.070 --> 08:36.900 However, if even this is not available, then the server the client is ready to accept any type any 08:36.900 --> 08:39.600 mime type with Q parameter 0.5. 08:39.990 --> 08:40.950 So. 08:42.420 --> 08:49.440 In this way, the client is telling to the server that I would prefer to have a PNG based image. 08:49.440 --> 08:57.060 If it is not available, then it goes to second, then the one with the lower Q parameter scores. 08:57.180 --> 09:03.210 So this is one of the ways in which the client can tell to the server about its own preferences. 09:03.210 --> 09:07.110 And in this way the content negotiation takes place. 09:08.460 --> 09:14.590 Now, the content negotiation even works as far as language is concerned. 09:14.610 --> 09:20.280 So here, as you see, as there is only one language, that means the client would prefer to have a 09:20.280 --> 09:25.530 content based on Ian slash us that is English based on us. 09:25.680 --> 09:32.220 So this language has a parameter of one as there is not defined by default. 09:33.480 --> 09:40.580 So this is one of the ways in which the Q parameter can help in the content negotiation. 09:40.590 --> 09:45.240 Even if you go to YouTube, there is a lot of content negotiation that takes place. 09:47.420 --> 09:50.720 To see what type of video quality a client would prefer. 09:51.880 --> 09:56.800 So this is it about the Q parameter and the basic content negotiation. 09:57.100 --> 10:01.240 I hope this video has been useful for you, and I'd like to thank you for viewing.