Is it possible to use enctype = "multipart / form-data" on a form that has no file input
On my server (which is running PHP 5.4), I have a generic way to deliver forms from database related objects. Some of the objects will have an input file and some will not. I would rather just set enctype="multipart/form-data"
instead of clearing the form (or database object) to see if it contains <input type="file" />
and conditionally.
I tested it with a form like <form enctype="multipart/form-data" action="blah" method="post"><input type="text" name="name" /></form>
and the data was received exactly the same (from the parameter $_POST
) as if I left the enctype blank.
So my test says everything is fine, but is there any reason why I should have left uncommented enctype="multipart/form-data"
for forms that do not contain a file?
source to share
The short answer is yes.
Slightly longer answer: yes, but you're increasing the size of the POST payloads (and thus increasing the time it takes to submit the form) ever slightly.
See what is actually sent to the browser for the POST request. I used nc(1)
to listen on a port and then used Firefox to blow it up with a request from a simple HTML page with two form fields:, foo
whose value was a
and bar
, whose value was b
.
Without specifying enctype
, the default browser will be application/x-www-form-urlencoded
. This is what was posted:
POST / HTTP/1.1 Host: localhost:9000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.1.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-CA,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://localhost/form.html Cookie: style=null; org.cups.sid=26d9134b774e3f9237c14f9f3fbe9082 Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 11 foo=a&bar=b
Fields are sent as key / value URLs, as in the request GET
. The only difference is that you can send more data. Just like pie.
The view multipart/form-data
, on the other hand, is considerably cumbersome:
POST / HTTP/1.1 Host: localhost:9000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Iceweasel/38.1.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-CA,en-US;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Referer: http://localhost/form.html Cookie: style=null; org.cups.sid=26d9134b774e3f9237c14f9f3fbe9082 Connection: keep-alive Content-Type: multipart/form-data; boundary=---------------------------1894318417527599887278201061 Content-Length: 277 -----------------------------1894318417527599887278201061 Content-Disposition: form-data; name="foo" a -----------------------------1894318417527599887278201061 Content-Disposition: form-data; name="bar" b -----------------------------1894318417527599887278201061--
URL encoding is ineffective for large amounts of binary data. Instead of sending one byte, you need to send three ( %xx
). By separating each field with an easily distinguishable boundary value (in this case -----------------------------1894318417527599887278201061
, but the browser will generate a new one for each request), the browser can send raw binary data. The obvious downside is that it incurs some serious overhead for small queries. In this simple example, a multi-page request is 25 times larger than a URL-encoded request. Again, in both cases, the time it takes to send the request body will be underestimated by the amount of time it takes to open the connection. But this is history for another day.
source to share
Logically speaking, the main reason you switched is to deal with files (since files cannot be encoded over application/x-www-form-urlencoded
). Aside from this control, none of them have any restrictions over the other (that's just how it is encoded).
The most notable difference is the overhead (in the form of more data based because it multipart/formdata
contains details that go beyond the name / meaning information).
For example, with the following view:
<form method="POST><!-- exempting encoding/action -->
<input type="text" name="greeting" value="Hello">
<input type="text" name="name" value="Brad">
<input type="submit" value="Submit">
</form>
With the default encoding ( application/x-www-form-urlencoded
), the answer could be:
greeting=Hello&name=Brad
Where it multipart/form-data
might look like:
-----------------------------1234567890
Content-Disposition: form-data; name="greeting"
Hello
-----------------------------1234567890
Content-Disposition: form-data; name="name"
Brad
-----------------------------1234567890
As you can see, there is a significant amount of additional overhead using multipart/form-data
enctype, which is usually explained when needed.
source to share