Html form content types

Content-Type

The Content-Type representation header is used to indicate the original media type of the resource (prior to any content encoding applied for sending).

In responses, a Content-Type header provides the client with the actual content type of the returned content. This header’s value may be ignored, for example when browsers perform MIME sniffing; set the X-Content-Type-Options header value to nosniff to prevent this behavior.

In requests, (such as POST or PUT ), the client tells the server what type of data is actually sent.

Header type	Representation header
Forbidden header name	no
CORS-safelisted response header	yes
CORS-safelisted request header	yes, with the additional restriction that values can’t contain a CORS-unsafe request header byte: 0x00-0x1F (except 0x09 (HT)), «():<>?@[\]<> , and 0x7F (DEL). It also needs to have a MIME type of its parsed value (ignoring parameters) of either application/x-www-form-urlencoded , multipart/form-data , or text/plain .

Syntax

Content-Type: text/html; charset=utf-8 Content-Type: multipart/form-data; boundary=something 

Directives

The MIME type of the resource or the data.

The character encoding standard. Case insensitive, lowercase is preferred.

For multipart entities the boundary directive is required. The directive consists of 1 to 70 characters from a set of characters (and not ending with white space) known to be very robust through email gateways. It is used to encapsulate the boundaries of the multiple parts of the message. Often, the header boundary is prepended with two dashes and the final boundary has two dashes appended at the end.

Examples

Content-Type in HTML forms

In a POST request, resulting from an HTML form submission, the Content-Type of the request is specified by the enctype attribute on the element.

form action="/" method="post" enctype="multipart/form-data"> input type="text" name="description" value="some text" /> input type="file" name="myFile" /> button type="submit">Submitbutton> form> 

The request looks something like this (less interesting headers are omitted here):

POST /foo HTTP/1.1 Content-Length: 68137 Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575 -----------------------------974767299852498929531610575 Content-Disposition: form-data; name="description" some text -----------------------------974767299852498929531610575 Content-Disposition: form-data; name="myFile"; filename="foo.txt" Content-Type: text/plain (content of the uploaded file foo.txt) -----------------------------974767299852498929531610575-- 

Specifications

Browser compatibility

BCD tables only load in the browser

See also

Found a content problem with this page?

This page was last modified on Apr 10, 2023 by MDN contributors.

Your blueprint for a better internet.

Источник

Understanding HTML Form Encoding: URL Encoded and Multipart Forms

Now, let us look at each form type with an example to understand them better.

URL Encoded Form

As the name suggests, the data that is submitted using this type of form is URL endcoded. Take the following form,

 action="/urlencoded?firstname=sid&lastname=sloth" method="POST" enctype="application/x-www-form-urlencoded">  type="text" name="username" value="sidthesloth"/>  type="text" name="password" value="slothsecret"/>  type="submit" value="Submit" />  

Here, you can see that the form is submitted to the server using a POST request, this means that it has a body. But how is the body formatted? It is URL encoded. Basically, a long string of (name, value) pairs are created. Each (name, value) pair is separated from one another by a & (ampersand) sign, and for each (name, value) pair, the name is separated from the value by an = (equals) sign, like say,

For the above form, it would be,
username=sidthesloth&password=slothsecret

Also, notice that we have some query parameters passed in the action URL, /urlencoded?firstname=sid&lastname=sloth .

Don’t the URL encoded body and the query parameters passed in the action URL look awfully similar? It’s because they are similar. They share the same format discussed above.

Try creating an HTML file with the above code and see how it’s submitted in the dev tools. Here is a snap,

The things to notice here are the Content-Type header which says application/x-www-form-urlencoded , the query string and the form fields are transferred to the server in the format as discussed above.

Note: Don’t get confused by the term Form Data in the screen shot. It’s just how Google Chrome represents form fields.

All is fine, but there is a little more to the encoding process. Let’s introduce some spaces in the submitted values, take the below form which is the same as the previous one but has the firstname value changed from sid to sid slayer and username value changed from sidthesloth to sid the sloth .

 action="/urlencoded?firstname=sid slayer&lastname=sloth" method="POST" enctype="application/x-www-form-urlencoded">  type="text" name="username" value="sid the sloth"/>  type="text" name="password" value="slothsecret"/>  type="submit" value="Submit" />  

Now try to submit the form and see how the form fields are transferred in the dev tools. Here is a dev tools snap in Chrome.

Clearly, you can see that the spaces are replaced by either ‘%20’ or ‘+’. This is done for both the query parameters and the form body.

Read this to understand when + and %20 can be used. This encompasses the URL encoding process.

Multipart Forms

Multipart forms are generally used in contexts where the user needs files to be uploaded to the server. However, we’ll just focus on simple text field based forms, as is it enough to understand how they work.

To convert the above form into a multipart form all you have to do is to change the enctype attribute of the form tag from application/x-www-form-urlencoded to multipart/form-data .

 action="/multipart?firstname=sid slayer&lastname=sloth" method="POST" enctype="multipart/form-data">  type="text" name="username" value="sid the sloth"/>  type="text" name="password" value="slothsecret"/>  type="submit" value="Submit" />  

Let’s go ahead and submit it and see how it appears in the dev tools.

There are the two things to notice here, the Content-Type header and the payload of the form request. Let’s go through them one by one.

Content-Type Header

The value of the Content-Type header is obviously multipart/form-data . But it also has another value, boundary . The value for this in the example above is generated by the browser, but the user can very well define it as well, say for example, boundary=sidtheslothboundary . We’ll get to see how it’s useful in the next section.

Request Body

The request payload contains the form fields themselves. Each (name, value) pair is converted into a MIME message part of the following format,

The above format is repeated for each (name, value) pair.

Finally, the entire payload is terminated by the boundary value suffixed with a — . So the entire request looks like,

Now, we see how the boundary value is used.

In the case of an application/x-www-form-urlencoded form, the & ampersand kind of acts as a delimiter between each (name, value) pair, enabling the server to understand when and where a parameter value starts and ends.

In the case of a multipart/form-data form, the boundary value serves this purpose. Say if the boundary value was XXX , the request payload would look like,

—XXX
Content-Disposition: form-data; name=»username»

sidthesloth
—XXX
Content-Disposition: form-data; name=»password»

The hyphens themselves are not part of the boundary value but rather needed as part of the request format. The Content-Type header for the above request would be,

Content-Type: multipart/form-data; boundary=XXX

This allows the browser to understand, when and where each field starts and ends.

Text/plain Forms

These forms are pretty much the same as the URL encoded forms, except that the form fields are not URL encoded when sent to the server. These are not used widely in general, but they have been introduced as a part of the HTML 5 specification.

Avoid using them as they meant for human understanding and not for machines.

Payloads using the text/plain format are intended to be human readable. They are not reliably interpretable by computer, as the format is ambiguous (for example, there is no way to distinguish a literal newline in a value from the newline at
the end of the value).

Hope, I was clear in explaining what I learnt..See you in the next one guys..Peace.. 🙂

Get to know more about me on my website..✨

Источник

The Differences Between HTML Form Content Types (enctype)

You’ve probably seen it before. The enctype attribute of an HTML Form element. But what does it mean?

At least form me, I almost never need to worry about what the content type is for a form. I use ASP.NET most of the time so this is automatically handled for me. But what if you’re not using a framework that handles this for you, or you’re rolling your own, or you need to post data to another system? Let’s see how changing the content type affects the POST.

You can change the content type to one of the following, per the W3C HTML5 Form spec:

How do we test?

Browser Dev Tools

First off, how do we see the differences? You can use the Chrome DevTools, or Firebug in Firefox, or probably the IE dev tools. WIth those tools there should be a way to view the requests that your browser makes. Here is an example of the “Net” tab in Firefox:

With the net tab open, you can click on any request and view the details about the request. You can see things like the Headers that were sent, the response, cookies that we passed, etc. Now that we know where to look, we can see what the differences are in the form content types.

Pro tip: Enable the persist button to track requests across multiple page loads. The list will get really long, but it will allow you to more easily compare multiple requests.

Pro Pro tip: I’ve never done this, but I believe that some of the dev tools will export the data listed in the Net tabs to a generic format. That data can be reloaded at a later time, or maybe used in some other way (diff tool?). Again, I’ve never used it but it may be helpful for extreme cases.

Proxies

While I didn’t really use them in creating this post, there are 2 powerful debugging proxies:

Proxies hook into your system at a lower level to potentially capture any HTTP traffic on your system. This can be really helpful in seeing requests across multiple browsers and other apps all in one place.

Test Form

Here is a little HTML form content type test page I’ve created that is setup with the different content types. It should be pretty self explanatory.

Test Results

Universally, when the content type is set for a form, that content type is passed as a header in the request:

Also, if you look at the Post Tab you will see how the data is encoded for the request:

Here is the full post data for each content type:

application/x-www-form-urlencoded (default):

test_field_1=Test&test_field_2=%21%40%23%24%25%5E%26*%28%29_%2B-%3D 

test_field_1=Test test_field_2=!@#$%^&*()_+-= 

multipart/form-data:

test_field_1=Test&test_field_2=%21%40%23%24%25%5E%26*%28%29_%2B-%3D -----------------------------21204402826745 Content-Disposition: form-data; name="test_field_1" Test -----------------------------21204402826745 Content-Disposition: form-data; name="test_field_2" !@#$%^&*()_+-= -----------------------------21204402826745-- 

As you can see above, the content type setting can have a drastic difference in how the data is contained in the request, and subsequently, how the server/framework/app on the other end needs to interpret it.

So when is this actually important?

TL;DR: PayPal and possibly other 3rd party services may expect a specific content type of an HTML Form POST.

As I mentioned earlier, this rarely comes up for me. However, this week I’m working on a PayPal integration and this was very important. In fact, if the content type was wrong on the form that posted payment information to PayPal a generic error would be thrown. This took me a while to track down since a regular HTML form worked fine, but when an ASP.NET form was pointed at the PayPal endpoint it break. This led to a lot of double-checking of code and values and testing with different parameters.

Eventually it came down to the fact that the form data was identical, but the posts were still giving different results. That’s when I remembered that ASP.NET typically works by having “one form to rule them all” on the page, and JavaScript is used to handle form posts (not AJAX, but JS code is triggered on submit). At that point I started looking at the details of the Net tab in Firefox, and that’s when I noticed the differences in Content Type! In my case the ASP.NET form was using the multipart/form-data content type, which PayPal was not cool with.

Published: October 30 , 2013

Источник