Are application/x-www-form-urlencoded and multipart/form-data the only 2 special content types treated by the client when sending data to server?

Question

I used to search and read posts related to this topic but now I am a little bit confused again.

As before, I read many posts but still didn't see any post clearly clarifying how these different content type would affect or maniuplate the client's data, when the client is sending data to server .

---

So here's my understanding (assume it's a POST method):

1. There are 2 content types are special and treated differently from the rest.
   application/x-www-form-urlencoded and multipart/form-data .

   • with application/x-www-form-urlencoded , the client's data is encoded (changed) in some ways.
   • with multipart/form-data , the client will use something called boundary as a delimiter. As a result, the client can send many stuffs all together in a single request with some boundary string inserted as delimiters.

2. And for all the other content types specified by the client ( xmlhttp.setRequestHeader ), eg application/json , application/pdf , application/image , application/octet-stream blablabla, the client won't change anything but just put the raw (binary) data in the http request body and send it to the server. The server can retrieve the raw data from the http request body and do whatever it wants.

Is my understanding/classfication correct?

---

By saying "client", I mean browser mostly.

By saying "server", I mean the server framework or applicaiton.

Because if I understand correctly, the web server eg Nginx or Apache won't do anything to the data. They just pass the data to the server-side application connected to them.

Answer 1

There are 2 content types are special and treated differently from the rest.

No. Those 2 content types (and text/plain which is pointless and you should never use) are supported by HTML forms.

with application/x-www-form-urlencoded, the client's data is encoded (changed) in some ways.

With a regular HTML form, all the encodings change the data in some way (even if it is text/plain s "Make everything be name=value and shove a new line between each item).

with multipart/form-data, the client will use something called boundary as a delimiter.

Yes. text/plain uses a new line. application/x-www-form-urlencoded uses a & . Everything has a delimiter. (You just can't tell the delimiter apart of a new line in the data in text/plain which is what makes it useless).

As a result, the client can send many stuffs all together in a single request with some boundary string inserted as delimiters.

The client can send many things with any of those three encodings.

The different is that multipart supports files.

Multipart lets you put headers before the data for each part, so you can include things like filenames and content-types which are almost essential for supporting files.

And for all the other content types specified by the client (xmlhttp.setRequestHeader), eg application/json, application/pdf, application/image, application/octet-stream blablabla, the client won't change anything but just put the raw (binary) data in the http request body and send it to the server.

Explicitly setting a content type has no effect on what the XMLHttpRequest object will do with what you pass to send() .

If you pass a string, it will not encode that in any way (so you need to encode the data into the string yourself and set the right content-type header for the encoding you picked). If you pass a FormData object then it will encode it as multipart. etc.

Because if I understand correctly, the web server eg Nginx or Apache won't do anything to the data. They just pass the data to the server-side application connected to them.

That's generally the case, but somewhat oversimplified. eg There may be no distinction between the server and the server-side application if it is written using Express.js running on Node.js.

---

Summary

• Forms always encode the data. The enctype attribute tells them which way to do it.
• XMLHttpRequest and fetch may encode the data, but it depends on what kind of value you pass to them. If it is a string, you have to encode it and set the right Content-Type yourself.