[Revised]
The answer is, because PHP doesn’t handle it (and it is not a bug):
https://bugs.php.net/bug.php?id=33741
Valid values for enctype in <form> tag are:
application/x-www-form-urlencoded
multipart/form-data
The first is the default, the second one you need only when you upload files.
@Alohci provided explanation why PHP doesn’t populate $_POST
array, but store the value inside a variable $HTTP_RAW_POST_DATA
.
Example of what can go wrong with text/plain
enctype:
file1.php:
<form method="post" enctype="text/plain" action="file2.php">
<textarea name="input1">abc
input2=def</textarea>
<input name="input2" value="ghi" />
<input type="submit">
</form>
file2.php:
<?php
print($HTTP_RAW_POST_DATA);
?>
Result:
input1=abc
input2=def
input2=ghi
No way to distinguish what is the value of input1
and input2
variables. It can be
- input1=
abc\r\ninput2=def
, input2=ghi
, as well as - input1=
abc
, input2=def\r\ninput2=ghi
No such problem when using the other two encodings mentioned before.
The difference between GET and POST:
- in GET, the variables are part of URL and are present in URL as query string, therefore they must be URL-encoded (and they are, even if you write
enctype="text/plain"
– it just gets ignored by the browser; you can test it using Wireshark to sniff the request packets), - when sending POST, the variables are not part of URL, but are sent as the last header in HTTP request (POSTDATA), and you can choose whether you want to send them as
text/plain
orapplication/x-www-form-urlencoded
, but the second one is the only non-ambiguous solution.