Welcome back.
Hope you're having fun.
Hope you're staying "amped".
Hope you've got a coffee â˜•.
Oh, man, I wish you could have some of this.
So nice.
But anyway, let's continue learning about this encoding type, specifically on the POST request.
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.
There's just a few things I want to mention.
Firstly, when we start setting this encoding type, this "enctype" attribute, what we're really doing...
is we're defining the Content-Type of the HTTP request.
And that's why we saw the Content-Type header was set to multipart/form-data.
But as we saw, there was another value called "boundary".
The value of this is generated by the browser itself.
We don't generate that value and the actual word itself is meaningless.
But you're going to be seeing shortly, and I'm going to be showing you, why it's useful for the server...
in a second.
But for now, just realize that this is what was set by the browser.
And that's the first thing I wanted to mention about this multipart/form-data.
The next thing I want to mention is the actual payload.
Firstly, the request payload contains the form fields themselves. In other words, each name:value...
pair is converted to the following format. There's that boundary name...
then we've got this Content-Disposition:form-data, and then we've got the names of each field in our
form.
And this format is repeated pretty much for every single name:value pair we have.
And finally, at the very end, the entire payload is going to be terminated by the boundary value suffixed...
with two hyphens --.
Have you got it?
That's just the general format of how your form data is sent to a server.
But you don't really need to memorize this.
But it's just good to know.
Now, this can get quite daunting ðŸ˜¨.
And for that reason, I want to harp on it, for a little bit more.
I want us to dig deeper into this whole boundary mechanism.
What is it all about and how does it work?
Let's start off by saying the boundary value is AAAA. Firstly, your message starts with two hyphens followed by
the boundary name.
In that case, it's going to be --AAAA.
That's how it starts.
And at the very end, we can see we've got our A's, which finishes off with those two hyphens I spoke
about,
right.
So there's the start. And there's the finish. Makes sense.
And then we've got the general format...
we just spoke about, the Content-Disposition: form-data, and then we've got the name of our, call it, form
field.
Here we've named it username. And then you've got the actual value below it,
WallyTheWarthog.
And of course, this continues for every item on your form.
The next name was favorite food, or favFood and of course its value was grass ðŸŒ¾. And this just continues...
all the way down.
Okay, so that's just the general format.
Don't get too confused with the hyphens.
Okay, the hyphens are not part of the boundary value, but they are required as part of the request
format.
It's just the formatting required.
We don't make these rules.
We have to follow them by the browser.
And of course, the Content-Type header for this specific example would be multipart/form-data and the
boundary value would be AAAA.
Got it?
Okay, okay.
Let's move on.
The bottom line is that the purpose of the boundary is to allow the browser and the server to understand...
when and where each field starts and ends. It's as simple as that. There's...
one more thing I want to mention about the multipart/form-data.
Just remember, characters are not encoded when we use multipart/form-data.
In other words, the file will be sent binary, and this will ensure that the bitstream is not altered...
in any way.
It basically just means your file won't be altered. All those special characters, those images in your...
file, won't be altered.
So it's very, very important to use multipart/form-data when sending binary forms.
And I want to talk about this "binary" in a bit more detail because it can be quite confusing.
Every file is just a collection of bytes, and could therefore be viewed as binary data.
But to confuse the layman, a distinction between text and non-text, hereafter "binary", has been established...
in the developer community. Text data is pretty straightforward.
It's just a sequence of Unicode code points, example of code points are characters like the "k" or that...
special funky Ã¤, as well as emojis,
the percentage sign. But pure text files are extremely rare.
So when we talk about binary data, we really talking about all data that is not pure text data.
In other words, a binary file consists of complex structured data meant primarily to be read by applications
that translate those structures into something useful to humans, like pictures, videos, richly formatted
text, etc, etc..
I imagine that pretty much 99% of people these days, except developers, never deal with text...
files directly.
Almost all content people care about, live in binary files.
And that's why this multipart/form-data type is so important.
Man, I love this stuff. ðŸ’• It's so cool.
Anyway, there's something I want to mention.
You might be thinking, "why don't we just always use multipart/form-data then Clyde, if its so easy...
and so cool?"
Well, for the simple reason that if you have only very simple characters in your form where you don't
need to do a lot of URL encoding, then the overhead of adding all the mime types or the mime headers,
you know, all those boundary words and all those dashes and numbers, well, that's going to outweigh the...
benefits of just URL encoding the original data and just sending it over the wire anyway.
So I guess the bottom line, what I'm trying to say, is that if you have very large binary files, then
use multipart/form-data.
But if you have a very simple form, not much characters going in there, just stick with the default,
that horrible long application/x-form-www ... or is it www-form-urlencoded!
I know it's a terrible word.
Don't know why they did it that way, but it is what it is.
So stick with that for short forms, and multipart/form-data for very complex forms.
Have you got it?
Great.
I know we've been through a lot.
But this is so interesting and it really is going to help you as a programmer.
So in conclusion, I can say that an HTML form is nothing more than a user friendly way to configure...
an HTTP request to send data to a server.
We're busy looking at the <form> element itself.
One of those important attributes is the encoding type attribute, and that's what these lectures have
been all about.
We've looked at GET requests, we've looked at POST requests, but at this point you might still be...
a little confused or not feeling 100% comfortable...
why multipart/form-data is preferred over application/x-www-form-urlencoded type, in certain circumstances.
And that's why I want to now jump into another lecture where we look at a very advanced example.
But enough blibber-blabber. Let's move on. (background music)