method="post" enctype="text/plain" are not compatible?

Question

When I use

<form method="post" enctype="text/plain" action="proc.php"> 

form data can not be sent to proc.php file properly. Why? What is the problem? Why I can't use text/plain encoding with post but I can use it with get method?

Spondylitis

I am pretty sure you don't need to define enctype, unless you are doing a file upload, then it should be: enctype="multipart/form-data" link – Firewarden

According to w3schools (link), application/x-www-form-urlencoded is default. – Interrogator

My question is why method=“post” and enctype=“text/plain” don't work together? My HTML code does not metter and what I should use does not matter too!!!!!!!!!!!!!!!!!!! – Spondylitis

What does "can not be sent to proc.php file properly" mean exactly? What does the resulting http post look like? – Mountainous

My html code was not figured in the text of the question, sorry. I have corrected. – Spondylitis

@Spondylitis I am assuming the browser doesn't know what to do with it since it isn't a valid token. I bet the browser treats enctype="text/plain" the same as enctype="cheeseburger", it does nothing.... – Firewarden

What's the use case for wanting to do this? What information would you expect the browser to put into the content of content type text/plain? – Transmittance

@Transmittance What is the use to use text/plain with get method? – Spondylitis

Actually, with method="post" enctype="text/plain", browser sends the data, and PHP stores it in $HTTP_RAW_POST_DATA, but it doesn't populate $_POST. Anyway, why you insist on having text/plain? – Interrogator

@Spondylitis - Get messages shouldn't have a content body at all. The HTTP 1.1 spec section 7.3 says "Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations to reject the request." – Transmittance

I have no idea why the question was closed. It's a good question which already has a very good answer. – Inaptitude

Answer 1

[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 or application/x-www-form-urlencoded, but the second one is the only non-ambiguous solution.

Interrogator

According to HTML5 text/plain is a third valid content-type for enctype. The format is described at dev.w3.org/html5/spec/…. – Transmittance

a nice table is here (I already posted it) – Interrogator

Frankly, I never believe a word w3schools says. – Transmittance

Okay, this one looks more credible pseudo-flaw.net/content/web-browsers/form-data-encoding-roundup ;) – Interrogator

$HTTP_RAW_POST_DATA is DEPRECATED in PHP 5.6, and REMOVED as of PHP 7.0. – Hidden

Answer 2

HTML5 does define how to format form data submitted as text/plain here: https://w3c.github.io/html/sec-forms.html#plain-text-form-data.

At the bottom of that section, it says:

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).

So it not unreasonable that PHP does not attempt to interpret it and only makes it available in raw form. To me, that seems the correct approach.

Transmittance

Broken link - you probably want html.spec.whatwg.org/multipage/… – Poult

@TomAnderson - Thanks. Updated link to latest W3C draft standard, but yes the WHATWG one you provide is equivalent. – Transmittance

I don't see the ambiguity if the form does not require newlines. – Poodle

Answer 3

if you're using enctype="text/plain" for debugging purposes, keep in mind that $_POST only contains associate array of variables passed to the current script via the HTTP POST method when using application/x-www-form-urlencoded or multipart/form-data as the HTTP Content-Type/enctype in the request. So you won't be able to see anything in the script if you're printing $_POSTin the php script.

Also there was a global variable called $HTTP_RAW_POST_DATA which is DEPRECATED in PHP 5.6, and REMOVED as of PHP 7.0. which you could have used to see raw form data as noted by N'Bayramberdiyev

Berck