WEBVTT 0 00:00.420 --> 00:01.380 Welcome back. 1 00:01.650 --> 00:02.340 Hope you're having fun. 2 00:02.370 --> 00:03.660 Hope you're staying "amped". 3 00:03.690 --> 00:04.380 Hope you've got a coffee ☕. 4 00:06.420 --> 00:09.170 Oh, man, I wish you could have some of this. 5 00:09.360 --> 00:09.900 So nice. 6 00:10.650 --> 00:16.380 But anyway, let's continue learning about this encoding type, specifically on the POST request. 7 00:17.520 --> 00:22.880 We just saw a really cool example, didn't we? And I hope it's starting to kind of sink in, how it all works. 8 00:22.890 --> 00:24.720 There's just a few things I want to mention. 9 00:25.560 --> 00:30.930 Firstly, when we start setting this encoding type, this "enctype" attribute, what we're really doing... 10 00:30.930 --> 00:36.060 is we're defining the Content-Type of the HTTP request. 11 00:36.660 --> 00:42.510 And that's why we saw the Content-Type header was set to multipart/form-data. 12 00:43.050 --> 00:47.190 But as we saw, there was another value called "boundary". 13 00:47.820 --> 00:50.910 The value of this is generated by the browser itself. 14 00:50.910 --> 00:54.750 We don't generate that value and the actual word itself is meaningless. 15 00:55.290 --> 00:59.910 But you're going to be seeing shortly, and I'm going to be showing you, why it's useful for the server... 16 00:59.910 --> 01:00.600 in a second. 17 01:00.960 --> 01:04.470 But for now, just realize that this is what was set by the browser. 18 01:04.860 --> 01:08.080 And that's the first thing I wanted to mention about this multipart/form-data. 19 01:09.060 --> 01:11.460 The next thing I want to mention is the actual payload. 20 01:12.440 --> 01:18.890 Firstly, the request payload contains the form fields themselves. In other words, each name:value... 21 01:18.890 --> 01:21.940 pair is converted to the following format. There's that boundary name... 22 01:22.550 --> 01:29.210 then we've got this Content-Disposition:form-data, and then we've got the names of each field in our 23 01:29.210 --> 01:29.660 form. 24 01:30.200 --> 01:35.640 And this format is repeated pretty much for every single name:value pair we have. 25 01:36.530 --> 01:44.240 And finally, at the very end, the entire payload is going to be terminated by the boundary value suffixed... 26 01:44.240 --> 01:46.040 with two hyphens --. 27 01:46.670 --> 01:47.310 Have you got it? 28 01:47.420 --> 01:52.030 That's just the general format of how your form data is sent to a server. 29 01:52.130 --> 01:53.660 But you don't really need to memorize this. 30 01:54.320 --> 01:55.560 But it's just good to know. 31 01:56.170 --> 01:58.430 Now, this can get quite daunting 😨. 32 01:58.670 --> 02:02.380 And for that reason, I want to harp on it, for a little bit more. 33 02:02.390 --> 02:05.710 I want us to dig deeper into this whole boundary mechanism. 34 02:06.080 --> 02:08.320 What is it all about and how does it work? 35 02:11.970 --> 02:18.000 Let's start off by saying the boundary value is AAAA. Firstly, your message starts with two hyphens followed by 36 02:18.000 --> 02:18.840 the boundary name. 37 02:18.900 --> 02:21.700 In that case, it's going to be --AAAA. 38 02:21.870 --> 02:22.740 That's how it starts. 39 02:22.740 --> 02:27.450 And at the very end, we can see we've got our A's, which finishes off with those two hyphens I spoke 40 02:27.450 --> 02:27.690 about, 41 02:27.690 --> 02:27.990 right. 42 02:28.260 --> 02:32.040 So there's the start. And there's the finish. Makes sense. 43 02:32.410 --> 02:33.750 And then we've got the general format... 44 02:33.750 --> 02:40.230 we just spoke about, the Content-Disposition: form-data, and then we've got the name of our, call it, form 45 02:40.230 --> 02:40.740 field. 46 02:41.100 --> 02:45.560 Here we've named it username. And then you've got the actual value below it, 47 02:45.600 --> 02:46.550 WallyTheWarthog. 48 02:46.800 --> 02:49.950 And of course, this continues for every item on your form. 49 02:50.220 --> 02:56.010 The next name was favorite food, or favFood and of course its value was grass 🌾. And this just continues... 50 02:56.010 --> 02:56.830 all the way down. 51 02:57.120 --> 02:58.700 Okay, so that's just the general format. 52 02:58.710 --> 03:00.850 Don't get too confused with the hyphens. 53 03:00.870 --> 03:06.270 Okay, the hyphens are not part of the boundary value, but they are required as part of the request 54 03:06.270 --> 03:06.710 format. 55 03:06.720 --> 03:08.120 It's just the formatting required. 56 03:08.250 --> 03:09.330 We don't make these rules. 57 03:09.330 --> 03:10.710 We have to follow them by the browser. 58 03:11.100 --> 03:17.100 And of course, the Content-Type header for this specific example would be multipart/form-data and the 59 03:17.100 --> 03:19.410 boundary value would be AAAA. 60 03:19.590 --> 03:20.040 Got it? 61 03:20.360 --> 03:21.300 Okay, okay. 62 03:21.570 --> 03:22.110 Let's move on. 63 03:23.310 --> 03:29.550 The bottom line is that the purpose of the boundary is to allow the browser and the server to understand... 64 03:29.550 --> 03:35.910 when and where each field starts and ends. It's as simple as that. There's... 65 03:35.910 --> 03:38.660 one more thing I want to mention about the multipart/form-data. 66 03:39.240 --> 03:44.210 Just remember, characters are not encoded when we use multipart/form-data. 67 03:44.640 --> 03:50.970 In other words, the file will be sent binary, and this will ensure that the bitstream is not altered... 68 03:50.970 --> 03:51.710 in any way. 69 03:51.720 --> 03:57.900 It basically just means your file won't be altered. All those special characters, those images in your... 70 03:57.900 --> 04:00.210 file, won't be altered. 71 04:00.810 --> 04:05.610 So it's very, very important to use multipart/form-data when sending binary forms. 72 04:06.240 --> 04:11.130 And I want to talk about this "binary" in a bit more detail because it can be quite confusing. 73 04:11.430 --> 04:16.920 Every file is just a collection of bytes, and could therefore be viewed as binary data. 74 04:17.100 --> 04:24.540 But to confuse the layman, a distinction between text and non-text, hereafter "binary", has been established... 75 04:24.540 --> 04:27.780 in the developer community. Text data is pretty straightforward. 76 04:27.780 --> 04:33.240 It's just a sequence of Unicode code points, example of code points are characters like the "k" or that... 77 04:33.240 --> 04:35.520 special funky ä, as well as emojis, 78 04:35.520 --> 04:40.760 the percentage sign. But pure text files are extremely rare. 79 04:41.010 --> 04:47.220 So when we talk about binary data, we really talking about all data that is not pure text data. 80 04:47.530 --> 04:53.760 In other words, a binary file consists of complex structured data meant primarily to be read by applications 81 04:53.760 --> 04:59.520 that translate those structures into something useful to humans, like pictures, videos, richly formatted 82 04:59.520 --> 05:01.330 text, etc, etc.. 83 05:01.830 --> 05:07.950 I imagine that pretty much 99% of people these days, except developers, never deal with text... 84 05:07.950 --> 05:09.240 files directly. 85 05:09.570 --> 05:13.680 Almost all content people care about, live in binary files. 86 05:14.550 --> 05:19.050 And that's why this multipart/form-data type is so important. 87 05:19.810 --> 05:21.420 Man, I love this stuff. 💕 It's so cool. 88 05:21.960 --> 05:23.370 Anyway, there's something I want to mention. 89 05:23.370 --> 05:30.630 You might be thinking, "why don't we just always use multipart/form-data then Clyde, if its so easy... 90 05:30.630 --> 05:31.260 and so cool?" 91 05:31.380 --> 05:36.660 Well, for the simple reason that if you have only very simple characters in your form where you don't 92 05:36.660 --> 05:43.620 need to do a lot of URL encoding, then the overhead of adding all the mime types or the mime headers, 93 05:43.620 --> 05:49.320 you know, all those boundary words and all those dashes and numbers, well, that's going to outweigh the... 94 05:49.320 --> 05:53.880 benefits of just URL encoding the original data and just sending it over the wire anyway. 95 05:54.090 --> 05:59.790 So I guess the bottom line, what I'm trying to say, is that if you have very large binary files, then 96 05:59.790 --> 06:01.980 use multipart/form-data. 97 06:02.430 --> 06:07.890 But if you have a very simple form, not much characters going in there, just stick with the default, 98 06:07.890 --> 06:15.420 that horrible long application/x-form-www ... or is it www-form-urlencoded! 99 06:15.690 --> 06:17.310 I know it's a terrible word. 100 06:17.610 --> 06:19.530 Don't know why they did it that way, but it is what it is. 101 06:19.800 --> 06:23.790 So stick with that for short forms, and multipart/form-data for very complex forms. 102 06:24.000 --> 06:24.570 Have you got it? 103 06:25.490 --> 06:25.850 Great. 104 06:28.200 --> 06:29.480 I know we've been through a lot. 105 06:30.730 --> 06:34.250 But this is so interesting and it really is going to help you as a programmer. 106 06:34.450 --> 06:41.680 So in conclusion, I can say that an HTML form is nothing more than a user friendly way to configure... 107 06:41.680 --> 06:46.180 an HTTP request to send data to a server. 108 06:46.600 --> 06:49.210 We're busy looking at the <form> element itself. 109 06:49.690 --> 06:55.300 One of those important attributes is the encoding type attribute, and that's what these lectures have 110 06:55.300 --> 06:56.330 been all about. 111 06:56.800 --> 07:02.080 We've looked at GET requests, we've looked at POST requests, but at this point you might still be... 112 07:02.080 --> 07:06.190 a little confused or not feeling 100% comfortable... 113 07:06.850 --> 07:15.730 why multipart/form-data is preferred over application/x-www-form-urlencoded type, in certain circumstances. 114 07:15.850 --> 07:21.070 And that's why I want to now jump into another lecture where we look at a very advanced example. 115 07:21.520 --> 07:23.970 But enough blibber-blabber. Let's move on. (background music)