PHP RFC for multipart/form-data handling on all verbs

[Nayte91]

Description

As this issue begin to grind my gears, and because API-Platform with the Symfony's support heavily uses REST architecture, I would like to propose a RFC to PHP.
@nicolas-grekas or @dunglas do you have, in few seconds (I don't want to bother you), resources about the whole topic? Anything besides the below resources should be known to begin? What about the PHP side?

Should this be an issue or a discussion?

Resources

• Last issue at Symfony's with discussion
• Previous abandoned PHP RFC with discussion
• HTTP/1.1 original 7231 RFC
• HTTP/1.1 update's 9110 RFC
• Multipart/form-data 2388 RFC
• $_REQUEST PHP doc
• $_POST PHP doc
• Actual "PUT method support" on PHP doc
• Actual "POST method uploads" on PHP doc
• "HTTP message interface" FIG's PSR-7

Example

The discussion around the previous abandoned RFC shows few interesting directions. Few questions:

• New superglobals $_GET, $_POST --> $_PUT, $_PATCH, .. ?
• What about $_FOO if a non-standard verb is used?
• What about disengaging PHP from those $_VERBS to have something more universal?
• The files should be found in $_FILES, regardless of the actual request method?
• What about an OOP API for the request? Or an interface?
• What about an enum for standardized verbs?
• Should PHP be agnostic about the HTTP standard (having a file with a GET request, accepting any Content-Type and any verb, ...) or should it allows/disallows requests in place of the web server/userland?
• Other ideas?

Those are ideas around the topic, and can be distributed into multiple RFC's. For now, sky is the limit.

Note: I can't implement as I don't know C. 😢

[derrabus]

I'm not sure if this is the right place to discuss this matter. This has be to resolved in PHP first, so this is where you need to take this discussion.

[Nayte91]

I'm not sure if this is the right place to discuss this matter. This has be to resolved in PHP first, so this is where you need to take this discussion.

Totally, it's more an occasion to gather important resources in order to write & discuss with PHP team. It's like a good start for me, as I need more information.

[Nek-]

I think a lot of people fully agree with the fact that something should be done about it. I believe that a better place for such discussion is: https://github.com/php/php-src/issues

About the content, I also agree that a newly oriented object API instead of using super-globals. This requires making a suggestion about the API and probably a lot of discussion and adjustments.

Finally, I think such work could be done with an extension before being taken at PHP-included level.

[derrabus]

New superglobals $_GET, $_POST --> $_PUT, $_PATCH, .. ?

No. The existing ones are fine despite being named badly.

What about an OOP API for the request? Or an interface?

Chose your battle. Id recommend to keep your RFC small and focused. Piggy-backing a whole new OOP API onto it will probably make it fail.

[Nayte91]

No. The existing ones are fine despite being named badly.

Do you mean that no NEW superglobals need to be created to handle request with other verbs? Do you think PUT/PATCH/WHATEVER content should be found in $_POST also?

Chose your battle. Id recommend to keep your RFC small and focused. Piggy-backing a whole new OOP API onto it will probably make it fail.

Absolutely, I think there is material for 3 or 4 RFCs here. 1st step is "just allow multipart handling for all verbs", but I feel like this is bound to how PHP parses the requests (if I am not mistaken), so a bit of foreshadowed design is welcome I guess?

[Nayte91]

An interesting part in the $_GET documentation > description:

Note that the array is not only populated for GET requests, but rather for all requests with a query string.

That's OK, PHP is agnostic about how you use your HTTP. But you don't find such a line in the $_POST documentation > description:

An associative 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 in the request.

Is there a room for the $_POST variable (and subsequently $_FILES) to be also agnostic about the method, and to populate the variables passed when using application/x-www-form-urlencoded or multipart/form-data? Something like:

An associative array of variables passed to the current script via the body when using application/x-www-form-urlencoded or multipart/form-data as the HTTP Content-Type in the request. Note that the array is not only populated for POST requests, but rather for all requests with a body and application/x-www-form-urlencoded or multipart/form-data as the HTTP Content-Type.

Then accept the files into the $_FILES superglobal, whatever verb used:

An associative array of items uploaded to the current script via the HTTP POST method. The structure of this array is outlined in the POST method uploads section.

Then can deprecate some special cases like "PUT method support", and change this "POST method uploads" doc to "Uploads".

Sounds like a plan for a first RFC "Allow file upload for any methods"?

[Nayte91]

I think a lot of people fully agree with the fact that something should be done about it. I believe that a better place for such discussion is: https://github.com/php/php-src/issues

As here are the future users of the feature, and the guys with knowledge to draft this one, I rather begin here and double this discussion on API-Platform side, then you're totally right, open on PHP issues as soon as I'm confident with our stuff!

About the content, I also agree that a newly oriented object API instead of using super-globals. This requires making a suggestion about the API and probably a lot of discussion and adjustments.

I don't know if PSRs ever reached the PHP code on some way, or if it's absolutely restricted to userland? PSR-7 can be a good starting point. Anyway, this is a "step 3" or "step 4" RFC way beyond this scope. Let's succeed with step 1 to begin 😄

Finally, I think such work could be done with an extension before being taken at PHP-included level.

Unfortunately, as discussed in this issue (by yourself!), we are in an infinite loop as the Symfony team thinks it's up to PHP to handle this issue.

Passing such an RFC would break a 27years old curse, as PUT appears in 1996's HTTP/1 RFC, and PATCH (as it's the actual other verb that would be used to upload a file) appears in 1997's HTTP/1.1 RFC.. Years where PHP was very dominant in the web usage. Is it a reason why other verbs than GET & POST aren't allowed in HTML forms? (note sure about the truth of this RFC)

...And I just figured out that I need to ensure that the above plan allows PATCH to work with file upload, as I think that a PATCH method must have a "merge/patch+json" Content-type?

[weierophinney]

The thing to remember is that PHP started in the late 90s, and at the time, anything other than GET or POST were pretty much unheard of. Over time, the meaning of $_GET and $_POST in PHP have come to mean:

• $_GET holds all query string arguments submitted in the request, regardless of HTTP method.
• $_POST is populated if the Content-Type is application/x-www-form-urlencoded and the HTTP method was POST, AND can also be populated from multipart/form-data.
• $_FILES is populated if a POST request comes in with a multipart content type that includes at least one file part.

Probably the easiest thing to do on the language side is to modify it such that any incoming request that has a request body populate the $_POST and $_FILES superglobals when possible. And, as everybody else has noted: that's something for an RFC submitted to php-internals.

Regarding this question of yours:

Is it a reason why other verbs than GET & POST aren't allowed in HTML forms? (note sure about the truth of this RFC)

The reason is because the HTML specification only allows "get", "post", and "dialog" for the "method" attribute of a form (or the "formmethod" attribute of a button/input element). (source)

Regarding this:

What about disengaging PHP from those $_VERBS to have something more universal?

I mean, that was kind of the point of PSR-7. 😉

[wouterj]

I'll close this issue here, as this is not the best place to discuss things like this (this tracker is used for bug reports and feature requests for Symfony). Feel free to continue this somewhere else (e.g. a GitHub discussion, on the PHP repo/mailing list/rfc, on Slack, etc.)

[hafezdivandari]

https://wiki.php.net/rfc/rfc1867-non-post