Default content-type and parsing of body for PUT and DELETE methods

[CodeCommander]

I noticed that when I make a PUT request to my Slim application it does not parse the body of the request unless I explicitly specified a Request Content-Type Header of "application/x-www-form-urlencoded". Another person also expressed the same issue here: http://help.slimframework.com/discussions/questions/4572-is-it-possible-to-make-put-request-with-multipartform-data

It appears this may be intentional based on these docs: http://docs-new.slimframework.com/objects/request/#request-body

However, contrary to those docs, the behavior is inconsistent between PUT and POST. The body is parsed for POST, even without specifying the Content-Type header.

This difference in the POST case seems to stem from this line here:

https://github.com/slimphp/Slim/blob/365dbfa0c02a31e76888eaec693dacd9dca1c82a/Slim/Http/Request.php#L352

I'm wondering why PUT and DELETE are not included in this line? In fact, is there a reason that "application/x-www-form-urlencoded" is not the assumed Content-Type if none is explicitly specified? This document seems to imply it is the default for HTML forms: http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

I want to change the default behavior for PUT and DELETE methods in my own app but I'd like to know if there is an intentional reason for the current behavior before I do. Thanks.

[netProphET]

Browsers do not make PUT or DELETE requests from HTML forms. Also, I do not believe that "application/x-www-form-urlencoded" is in any way a standard content type for REST requests. It can be used but it should not be assumed.

[Lewiscowles1986]

This is a problem that has been on my mind also, although I am not sure if a Slim problem, or a PHP problem...

Would it not be more "intelligent" for lack of a better term to advise native parsing of POST data be switched off in the PHP ini file, and not parse anything; as it is a default behavior of PHP to assume POST data is form encoded, and not deal with any other formats or methods outside of POST.

As a reference, please see http://php.net/manual/en/ini.core.php#ini.enable-post-data-reading

[akrabat]

You can safely assume that no one will ever turn off POST parsing.

The reason that only POST is checked for isFormData is that PHP only fills in $_POST for POST requests. If you're using PUT, then supply the correct Content-Type header.

[Lewiscowles1986]

You can safely assume that no one will ever turn off POST parsing.

Actually I do, and it makes my PHP serve requests faster (although marginally); and guarantees me, that if I should want to deal with POST, or any data from request, PHP won't provide a confusing alternative...

It seems absolutely mind-boggling to me that you think anyone took the time to implement turning off a feature; (thereby implementing their own feature, likely needing testing) without there being a valid use-case...

To quote the manual

This can be useful to proxy requests or to process the POST data in a memory efficient fashion.

[akrabat]

Netcraft thinks that there are around 80million active PHP websites, How many do you think have POST turned off?

By "no one", I meant "a vanishingly small percentage"

[Lewiscowles1986]

This is probably not the right place for this discussion, but it was only introduced as a fairly recent feature, so unless either of us can get numbers I think it's fair to conclude neither has the ability to quote researched numbers; the merits of my case is that I feel the existence and mention of the feature in the manual, as I have written; suggests to me, it's not that niche a feature...

enable_post_data_reading "1" PHP_INI_PERDIR Available since PHP 5.4.0 http://php.net/manual/en/ini.core.php#ini.sect.data-handling

N.B. Please do not come back with I run N servers that don't, because I'll just come back with how many servers I use that do, and it will mean nothing, just like the netcraft figures, which don't cover this setting.