Re: [PHP-DEV] New globals for PUT and DELETE
On 10/28/14, 11:25 AM, Michael Wallner wrote: On 28/10/14 16:58, Ben Ramsey wrote: On Oct 26, 2014, at 4:30 PM, Will Fitch willfi...@php.net wrote: 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. I would be supportive of this, and I’ll even volunteer to help make this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal. This already is v2, and PHP-FIG has been, well, I don't know how to call that, dismissive(?) about the invitation to discuss. We have? FIG's been discussing PSR-7 a lot lately. :-) You're welcome to join in. Our general stance is that request information should be read from an object, not a superglobal, though. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 26, 2014, at 4:30 PM, Will Fitch willfi...@php.net wrote: 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. I would be supportive of this, and I’ll even volunteer to help make this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal. -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
1. Sure, but the frustrating thing is that the C code (for mime-parsing) is already there and just not being used for non-POST methods. Why make everyone use pecl/framework code that duplicates what exists in PHP already (albeit for POST only)? 2. You're right. That would be too many. That's why adding a single new variable of $_FORM/BODY/foo would work for everything (including POST). Of course, $_FILES (whose name is already method-agnostic) should be populated too and not restricted to POST only. On 26 October 2014 14:21, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would It is true that PUT data need to be parsed, however it is not true you have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if you want to do WebDAV? Wouldn't having separate superglobal for each be taking it a bit too far? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/
Re: [PHP-DEV] New globals for PUT and DELETE
On 28/10/14 16:58, Ben Ramsey wrote: On Oct 26, 2014, at 4:30 PM, Will Fitch willfi...@php.net wrote: 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. I would be supportive of this, and I’ll even volunteer to help make this happen with a v2 that adheres to the PHP-FIG’s PSR-7 proposal. This already is v2, and PHP-FIG has been, well, I don't know how to call that, dismissive(?) about the invitation to discuss. Anyway, there's not been a single question since the RFC announcement, except about the dependencies, so either nobody is interested, or those who use it are fine with it. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
$_FILES (whose name is already method-agnostic) The name appears method-agnostic but the implementation obviously isn't. It works with multipart/form-data, which is tightly coupled with POST, but which isn't the only way to transfer files, not by a long shot. If you ignore the HTTP method you're being completely arbitrary if you still only decode form-data into $_FILES. For example we PUT and POST bytearray/binary files thousands of times per day. You can PUT application/xml as a valid file, heck, you can PUT a tarball, a great way to send multiple files. Would the enhanced $_FILES be populated in those cases? And if not, why not? -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 26/10/14 22:21, Stas Malyshev wrote: Hi! The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would It is true that PUT data need to be parsed, however it is not true you have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? Yes, see here: http://devel-m6w6.rhcloud.com/mdref/http/Env http://devel-m6w6.rhcloud.com/mdref/http/Env/Request http://devel-m6w6.rhcloud.com/mdref/http/Message http://devel-m6w6.rhcloud.com/mdref/http/Message/splitMultipartBody http://devel-m6w6.rhcloud.com/mdref/http/Message/Body -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
there's really nothing missing from PHP today to enable successful easy implementation of RESTful interfaces. Zeev, I could not create a REST interface that accepted multipart form data in uploading a file and form data in one PUT request. This is a valid part of a RESTful interface, yet PHP does not provide parsed data and file data for PUT like it does for POST (in the form of $_FILES and $_POST). The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would rather rely on the more-well tested parser which exists in PHP itself for POST. (A side-note: in my case it was deemed less risky to employ a load-balancer hack instead). Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). Dave. On 14 October 2014 14:56, Zeev Suraski z...@zend.com wrote: Personally, I like the idea of using more appropriately named aliases, particularly if they're roughly the same number of characters. However, we would need to allow at least several years for people to adopt the new globals before deprecating $_GET and $_POST. Ultimately, they will either need to be deprecated or the $_PUT and $_DELETE aliases will need to be added, otherwise the issue I raised would remain unresolved. Kris, Don't get this the wrong way, but $_GET and $_POST are not going to be deprecated. Whether or not we need $_PUT or $_DELETE is a separate, independent question from the axiom that $_GET and $_POST are here to stay. Personally, I don't think they make sense as Rasmus pointed out that $_GET and $_POST were never about HTTP methods but form methods, and there's really nothing missing from PHP today to enable successful easy implementation of RESTful interfaces. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. In addition to PECL HTTP, you might try PECL Mailparse, which is also going to be better-tested than anything written in userland. I sympathize with your overall point: even without a new superglobal, it would be cool to be able to reuse the same parser from $_POST. Still, just to put this out there: receiving multiparts via PUT can be part of a legit RESTful interface, but that doesn't mean that decoding multiparts should be automatic. It shouldn't be surprising that it PHP treats the entity as an opaque block of data by default, since it's perfectly RESTful for _the MIME-encoded body_ to be the stored resource. Imagine an e-mail archive that PUTs to /user/$username/sent/$messageid. Decoding the MIME message on resource create/update would be inappropriate in that case, a huge waste of resources. You might lazy-decode the resource only upon GET /user/$username/sent/$messageid/part/1. Within the same installation, you might want to decode other PUTs upon upload, so having a simple on/off for a new superglobal wouldn't work. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi! The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would It is true that PUT data need to be parsed, however it is not true you have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if you want to do WebDAV? Wouldn't having separate superglobal for each be taking it a bit too far? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi! On Sun, Oct 26, 2014 at 10:21 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would It is true that PUT data need to be parsed, however it is not true you have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if you want to do WebDAV? Wouldn't having separate superglobal for each be taking it a bit too far? I think Rasmus made it clear what the original naming meant: it were form methods, not related at all to HTTP methods. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Regards, -- Florian Margaine
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 26, 2014, at 4:21 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! The only way to do this in PHP now is write a userland function that parses multipart form data, which is non-trivial. I had written one, but would It is true that PUT data need to be parsed, however it is not true you have to implement MIME parsing from scratch. There are frameworks that implement that. Not everything must be written in C. But if you want C, doesn't pecl/http already have the required bits? 100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core should be the real discussion: https://wiki.php.net/rfc/pecl_http https://wiki.php.net/rfc/pecl_http. Having the ability to access the data provided in $_POST for other methods is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc). There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if you want to do WebDAV? Wouldn't having separate superglobal for each be taking it a bit too far? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-26 23:24 GMT+02:00 Florian Margaine flor...@margaine.com: I think Rasmus made it clear what the original naming meant: it were form methods, not related at all to HTTP methods. Yes, this would be logical to have access to the input data, as single interface, do not make exceptions for POST, input data send methods PUT, DELETE, must be available in a single global variable, the variable name is not important file_get_contents(‘php://input') - uncomfortably -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 26, 2014, at 5:00 PM, Park Framework park.framew...@gmail.com wrote: 2014-10-26 23:24 GMT+02:00 Florian Margaine flor...@margaine.com: I think Rasmus made it clear what the original naming meant: it were form methods, not related at all to HTTP methods. Yes, this would be logical to have access to the input data, as single interface, do not make exceptions for POST, input data send methods PUT, DELETE, must be available in a single global variable, the variable name is not important file_get_contents(‘php://input') - uncomfortably Or, use pecl/http to handle it. GET/POST are form relative while all others are HTTP related. That’s been said quite a few times in this thread. You don’t have to use php://input php://input. pecl/http is available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 26, 2014, at 10:38 PM, Sanford Whiteman figureone...@gmail.com wrote: pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. I’m confused. pecl/http does have Windows binaries: http://windows.php.net/downloads/pecl/releases/http/ http://windows.php.net/downloads/pecl/releases/http/. Did I miss something? -- S.
Re: [PHP-DEV] New globals for PUT and DELETE
You're right. Guess the build system didn't update http://pecl.php.net/package/pecl_http with the DLL link as for other exts. -- S, On Mon, Oct 27, 2014 at 12:31 AM, Will Fitch willfi...@php.net wrote: On Oct 26, 2014, at 10:38 PM, Sanford Whiteman figureone...@gmail.com wrote: pecl/http is available To a degree, but no binaries for Windows == not a universal prescription. Mailparse by contrast does have a shipping DLL. I’m confused. pecl/http does have Windows binaries: http://windows.php.net/downloads/pecl/releases/http/. Did I miss something? -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
PUT, DELETE, must be available in a single global variable, the variable name is not important file_get_contents(‘php://input') - uncomfortably If the quibble were with file_get_contents(‘php://input') that's not sufficiently uncomfortable to warrant a new superglobal. I assume you mean parsing the contents of php://input into an associative array regardless of the content-type of the HTTP entity-body. However, you're glossing over the semantic difference between POSTing an entity-body and PUTing that same body. multipart/form-data is specified in RFC 1867 as POST-specific, with deliberate notes about expected server behavior. RFC 2388 expands form-data into a general mimetype regardless of transport, and theoretically regardless of HTTP method, but AFAIK there's no equivalent to 1867 that reasonably leads to auto-decoding PUT form-data into an associative array. Rather, the PUT payload has always been designed to _become_ the target resource, as-is. The POST payload is designed to be interpreted via the server's own semantics before changing any resource state. Thus there is a very strong reason to present POST data to the server in an easily accessible and mutable form. Not so for PUT. This doesn't mean PUT payloads must stay opaque to PHP, of course. If there's a need to validate the payload before overwriting the current resource state, that may require that it be passed through some binary image verification, validated against a DTD, or -- indeed -- decoded from multipart MIME into its parts for validation, even if it's the multipart representation that eventually gets stored. Yet if you feel that PUT content should be automatically decoded, you might as well apply this to other multipart content as well -- if I PUT an MHTML file or, as noted before, an RFC 822 e-mail, by this assumption those would also populate the new superglobal. Honestly if it didn't consume any extra resources to always populate, I wouldn't care. But to be unable to avoid decoding every giant multipart payload just because I _might_ want to look at the parts is highly inefficient. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-15 4:30 GMT+03:00 Stas Malyshev smalys...@sugarcrm.com: Hi! PHP today to enable successful easy implementation of RESTful interfaces. Having done this, I beg to differ. Try to send a parameter in the body, by PUT method, for reading parameters have to use an ugly way file_get_contents(‘php://input') What exactly is the problem in this one-liner? But yet worst, you can not do upload files and send parameters because - php://input is not available with enctype=multipart/form-data I'm not sure I understand what you're trying to do, could you explain in more detail with examples? PUT /url Content-type: application/x-www-form-urlencoded parse_str (file_get_contents(‘php://input'), $_POST) // Ok PUT /url Content-type: multipart/mixed; boundary= file_get_contents(‘php://input') // Empty string -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
I'm not sure I understand what you're trying to do, could you explain in
more detail with examples?
PUT /url
Content-type: application/x-www-form-urlencoded
parse_str (file_get_contents(‘php://input'), $_POST) // Ok
PUT /url
Content-type: multipart/mixed; boundary=
file_get_contents(‘php://input') // Empty string
You are missing information in your example. First, PHP doesn't do
content negotiation for every Content-Type known to send serialized
data, it is extremely selective in that AFAIK, url/form encoded
Content-Types, when POSTed, will be content-negotiated, parsed, and
their resultant will populate the $_POST superglobal.
Moreover, your 2nd example does not suggest that an HTTP request was
sent with a body to demonstrate there is a bug here.
With a php script being served at index.php with the following contents:
?php
var_dump(file_get_contents('php://input'));
Here is a demonstration of this script, and a successful read of the
request body:
$ echo 'F=BAR' | http --verbose PUT localhost:8000 \
Content-Type:'multipart/mime; boundry=x'
PUT / HTTP/1.1
Accept: application/json
Accept-Encoding: gzip, deflate
Content-Length: 14
Content-Type: multipart/mime; boundry=x
Host: localhost:8000
User-Agent: HTTPie/0.8.0
F=BAR
HTTP/1.1 200 OK
Connection: close
Content-type: text/html
Host: localhost:8000
X-Powered-By: PHP/5.5.15
string(14) F=BAR
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 15 October 2014 22:14:32 GMT+01:00, Ralph Schindler ra...@ralphschindler.com wrote: I'm not sure I understand what you're trying to do, could you explain in more detail with examples? PUT /url Content-type: application/x-www-form-urlencoded parse_str (file_get_contents(‘php://input'), $_POST) // Ok PUT /url Content-type: multipart/mixed; boundary= file_get_contents(‘php://input') // Empty string Here is a demonstration of this script, and a successful read of the request body: $ echo 'F=BAR' | http --verbose PUT localhost:8000 \ Content-Type:'multipart/mime; boundry=x' PUT / HTTP/1.1 Accept: application/json Accept-Encoding: gzip, deflate Content-Length: 14 Content-Type: multipart/mime; boundry=x Host: localhost:8000 User-Agent: HTTPie/0.8.0 I'm not sure if itmakes a difference, but you mistyped the content type there: it should be `multipart/mixed`, not `multipart/mime`. There may also be version differences at play here, because I think the behaviour of php://input has been changed a couple of times. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi!
?php
if($_SERVER['REQUEST_METHOD'] == 'POST')
{
var_dump(file_get_contents('php://input'));
exit;
}
I tried this script, if you do POST, your data is in $_FILES, if you do
PUT, your data is in php://input. Still not sure what is the big problem.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-16 2:13 GMT+03:00 Stas Malyshev smalys...@sugarcrm.com:
I tried this script, if you do POST, your data is in $_FILES, if you do
PUT, your data is in php://input. Still not sure what is the big problem.
I added the variable field, how do I get its value, with use the query
method PUT and enctype=multipart/form-data?
This debate not for tediousness, this is a real problem, if you want
to use the query method PUT and enctype=multipart/form-data,
variable $_POST is empty and file_get_contents('php://input') is empty
?php
if($_SERVER['REQUEST_METHOD'] == 'POST')
{
var_dump(file_get_contents('php://input'));
exit;
}
?html
body
form method=POST enctype=multipart/form-data
input type=hidden name=key value=value
input type=file name=file
hr
buttonPOST/button
/form
/body
/html
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi!
I added the variable field, how do I get its value, with use the query
method PUT and enctype=multipart/form-data?
This debate not for tediousness, this is a real problem, if you want
to use the query method PUT and enctype=multipart/form-data,
variable $_POST is empty and file_get_contents('php://input') is empty
No, file_get_contents('php://input') is not empty - I just checked it
and if you send PUT request the whole request - files and all - is in
the php://input. If you don't see it you might be doing something wrong.
You are talking about PUT, but post example about POST for the second
time. I'm not sure what you mean by that as certainly your script does
not demonstrate what you are saying.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-16 2:36 GMT+03:00 Stas Malyshev smalys...@sugarcrm.com:
No, file_get_contents('php://input') is not empty - I just checked it
and if you send PUT request the whole request - files and all - is in
the php://input. If you don't see it you might be doing something wrong.
Yes, you're right, I'm wrong tests, send PUT
enctype=multipart/form-data - php://input - is not empty, sorry.
But parse multi part in the PHP script is not very good solution, can
use pecl-ext HTTP, but it is better if there are an global array of
$_BODY.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New globals for PUT and DELETE
Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
Last time it stranded here: https://www.mail-archive.com/internals@lists.php.net/msg67294.html And I believe it's been up a number of times before that. On 14 October 2014 14:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? --Kris -- hype WWW: plphp.dk / plind.dk CV: careers.stackoverflow.com/peterlind LinkedIn: plind Twitter: kafe15 /hype
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? $_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data. We should just put the request bodies for all requests, not just POST, into $_POST. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? $_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data. We should just put the request bodies for all requests, not just POST, into $_POST. -- Andrea Faulds http://ajf.me/ The problem with that approach though is that it would not be RESTful. I'm developing a REST API (with the goal of 100% REST compliance) and having PUT/DELETE variables mixed in with $_POST would not only be counter-intuitive, but it would just present a new roadblock. Incorporating GET in there, as well, would make things even worse. Basically, if we have $_GET and $_POST, then we should also have $_PUT and $_DELETE. Either that, or they should all be tossed. There's no reason why $_PUT and $_DELETE should not also exist. --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014, at 7:47 AM, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? —Kris This is due to the history of HTML forms sending POST requests with the Content-Type application/x-www-form-urlencoded. That is, all the fields are key/value pairs and may be easily converted into a PHP array. If you use POST with application/json, nothing appears in $_POST, for example. In practice, we could support $_PUT and $_DELETE for requests that use application/x-www-form-urlencoded, but most folks implementing PUT and DELETE do not use application/x-www-form-urlencoded for these requests. I would venture to say that most people implementing PUT requests accept application/json and most DELETE requests have no body at all. So, $_PUT and $_DELETE superglobals wouldn’t make sense. -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 6:09 AM, Ben Ramsey b...@benramsey.com wrote: On Oct 14, 2014, at 7:47 AM, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? —Kris This is due to the history of HTML forms sending POST requests with the Content-Type application/x-www-form-urlencoded. That is, all the fields are key/value pairs and may be easily converted into a PHP array. If you use POST with application/json, nothing appears in $_POST, for example. In practice, we could support $_PUT and $_DELETE for requests that use application/x-www-form-urlencoded, but most folks implementing PUT and DELETE do not use application/x-www-form-urlencoded for these requests. I would venture to say that most people implementing PUT requests accept application/json and most DELETE requests have no body at all. So, $_PUT and $_DELETE superglobals wouldn’t make sense. -Ben I'm not following your logic, Ben. Just because there are a lot of people out there who don't understand REST, doesn't mean we shouldn't add support for the other methods. Besides, if anyone wants to develop a truly RESTful API in PHP-- which a lot of devs are doing every day-- not giving them $_PUT and $_DELETE is what wouldn't make any sense. I'm writing an API now and the lack of those two globals has proven to be a real pain in the ass. The Content-Type argument really isn't an issue since the API developer should be setting the right headers for the request method, anyway. I don't see any gain in not making those globals available. All it does is present both inconvenience and inconsistency for any REST-based project. --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
Kris Craig wrote (on 14/10/2014): The problem with that approach though is that it would not be RESTful. I'm developing a REST API (with the goal of 100% REST compliance) and having PUT/DELETE variables mixed in with $_POST would not only be counter-intuitive, but it would just present a new roadblock. This makes no sense; there is no such thing as PUT/DELETE variables in HTTP, any more than there is such things as POST variables. Just imagine that the variables are called $_QUERY_STRING and $_REQUEST_BODY. They should be completely orthogonal to the request method. Note that this is already true to an extent - you can access the query string through $_GET on a POST request, and $_POST will exist as an empty array. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014, at 8:09 AM, Kris Craig kris.cr...@gmail.com wrote:
On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds a...@ajf.me wrote:
On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote:
Hey guys,
Does anybody know why we have $_GET and $_POST, but not $_PUT and
$_DELETE? As far as I can tell, the only way to get these out currently
is
to parse their values by reading the incoming stream directly.
Is there a reason why we don't want this or is it just that nobody has
actually written it yet?
$_GET and $_POST are really misnomers. $_GET is query string parameters,
$_POST is request body data.
We should just put the request bodies for all requests, not just POST,
into $_POST.
The problem with that approach though is that it would not be RESTful. I'm
developing a REST API (with the goal of 100% REST compliance) and having
PUT/DELETE variables mixed in with $_POST would not only be
counter-intuitive, but it would just present a new roadblock.
Incorporating GET in there, as well, would make things even worse.
Basically, if we have $_GET and $_POST, then we should also have $_PUT and
$_DELETE. Either that, or they should all be tossed. There's no reason
why $_PUT and $_DELETE should not also exist.
Putting everything into $_POST isn’t a question of being RESTful or not. REST
in a
Web application happens at the HTTP protocol level and not the PHP level.
That said, it would be confusing to place the request body for all requests
into $_POST.
You also have to consider PATCH and the potential body for other HTTP methods.
The
easiest way to get the body of any HTTP request is to use the input stream:
$requestBody = file_get_contents('php://input');
I suppose we could make a super global that returns that for us, but it’s just
as easy to
use the above. Additionally, you might not want to put the full body of the
request into
memory like that. You might rather read the stream only a few bytes at a time.
-Ben
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 4:09 PM, Kris Craig kris.cr...@gmail.com wrote: On Tue, Oct 14, 2014 at 5:54 AM, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? $_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data. We should just put the request bodies for all requests, not just POST, into $_POST. -- Andrea Faulds http://ajf.me/ The problem with that approach though is that it would not be RESTful. I'm developing a REST API (with the goal of 100% REST compliance) and having PUT/DELETE variables mixed in with $_POST would not only be counter-intuitive, but it would just present a new roadblock. Incorporating GET in there, as well, would make things even worse. Basically, if we have $_GET and $_POST, then we should also have $_PUT and $_DELETE. Either that, or they should all be tossed. There's no reason why $_PUT and $_DELETE should not also exist. --Kris This has nothing to do with REST. $_GET doesn't even relate to GET requests, it's just query parameters. Query parameters exist in all types of requests because they are part of the URI. $_POST (even if only parsed for POST requests) also represents just the request body parsed from a very specific format. There's no reason to have $_PUT, $_DELETE, etc. because they would represent the same thing - php://input parsed from application/x-www-form-urlencoded. That being said, from a purely semantic prospective, both $_GET and $_POST should be tossed - yes. In reality, you can't do that because virtually all PHP applications use them. But this is no reason to add even more global vars with such misleading ... meanings. What would be nice is to be able to register userland parsers into a request body parser of some kind, so that you can have automatic parsing depending on the Content-Type header. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Kris Craig wrote (on 14/10/2014): The Content-Type argument really isn't an issue since the API developer should be setting the right headers for the request method, anyway. I think the point is that there's currently no mechanism for data from anything other than application/x-www-form-urlencoded and multipart/form-data to end up in $_POST anyway. There was a discussion of that a while back, and I think there's talk on PHP-FIG about how standardising HTTP interfaces. It comes down to needing some flexibility over /how/ different content types are parsed, which makes a function-call based API make more sense than one that silently slurps the data on every page load.
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 14:23, Andrey Andreev n...@devilix.net wrote: That being said, from a purely semantic prospective, both $_GET and $_POST should be tossed - yes. In reality, you can't do that because virtually all PHP applications use them. But this is no reason to add even more global vars with such misleading ... meanings. Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 9:25 AM, Andrea Faulds a...@ajf.me wrote: Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names. $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014, at 8:25 AM, Andrea Faulds a...@ajf.me wrote: Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names. But they are neither the request body nor the query string at that point. They are arrays that represent them. I agree that $_GET and $_POST are left-overs from a bygone day. Introducing aliases adds more confusion, IMHO. -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 October 2014 14:25, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 14:23, Andrey Andreev n...@devilix.net wrote: That being said, from a purely semantic prospective, both $_GET and $_POST should be tossed - yes. In reality, you can't do that because virtually all PHP applications use them. But this is no reason to add even more global vars with such misleading ... meanings. Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names. $_BODY and $_QUERY would be better, IMHO. The brevity would be consistent both historically and with other existing superglobal names, and at least with $_QUERY_STRING the data is not a string. I suggested this a while ago, people didn't like the idea, and I'm not sure I do any more, either. We'd do much better focusing on creating a standard native request *object* which provides clean access to this data, and other things that are clumsy at the moment, such as request headers. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014, at 8:30 AM, Chris Wright c...@daverandom.com wrote: I suggested this a while ago, people didn't like the idea, and I'm not sure I do any more, either. We'd do much better focusing on creating a standard native request *object* which provides clean access to this data, and other things that are clumsy at the moment, such as request headers. Agreed, and it seems that’s what PHP-FIG is working on for user land: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY - request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? -- Andrea Faulds http://ajf.me/ +1 for this. This would hopefully also eliminate the confusion for new developers (or not-so-new developers) who don’t quite understand that $_GET and $_POST don’t strictly relate to their HTTP verbs of the same name. -- Mike Dugan m...@mjdugan.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 6:25 AM, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 14:23, Andrey Andreev n...@devilix.net wrote: That being said, from a purely semantic prospective, both $_GET and $_POST should be tossed - yes. In reality, you can't do that because virtually all PHP applications use them. But this is no reason to add even more global vars with such misleading ... meanings. Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names. -- Andrea Faulds http://ajf.me/ I don't think that would be a good idea, either. They require more typing and it'd probably be a lot easier for devs to remember which one means GET and which one means POST. The fact that $_PUT and $_DELETE aren't necessary because we can use other approaches to get that data is irrelevant. Having globals for two REST methods but not the other two is very counter-intuitive from a dev standpoint. We just recently discussed how PHP tends to have duplicate ways of doing something in order to make it as easy as possible. I believe this is one of those times. It would make it a lot easier for devs, particularly the ones less experienced with REST, to create APIs that actually use the correct methods without running into the confusion over why there's a $_GET and a $_POST but not a $_PUT or a $_DELETE. PHP is supposed to be KISS, right? Well, the current reliance on php://input for two methods but not the other two invites confusion. That makes it less-than simple, I believe. Removing or renaming $_GET and $_POST would also create confusion and almost certainly cause widespread BC breakage on a pretty massive scale. And there's really no gain to offset that. So that just leaves us with either continuing to have two REST methods but not the others or add a $_PUT and a $_DELETE, even if they just alias to php://input again. --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY - request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? -- Andrea Faulds http://ajf.me/ +1 for this. This would hopefully also eliminate the confusion for new developers (or not-so-new developers) who don’t quite understand that $_GET and $_POST don’t strictly relate to their HTTP verbs of the same name. -- Mike Dugan m...@mjdugan.com That could work, though the BC breakage will be extreme. I'm not sure if that's worth it even in a major version increment. On the other hand, making $_PUT and $_DELETE available wouldn't break anything and wouldn't require re-training for devs. --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
-- Mike Dugan m...@mjdugan.com On October 14, 2014 at 9:42:47 AM, Kris Craig (kris.cr...@gmail.com) wrote: On Tue, Oct 14, 2014 at 6:25 AM, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 14:23, Andrey Andreev n...@devilix.net wrote: That being said, from a purely semantic prospective, both $_GET and $_POST should be tossed - yes. In reality, you can't do that because virtually all PHP applications use them. But this is no reason to add even more global vars with such misleading ... meanings. Let’s add $_REQUEST_BODY and $_QUERY_STRING and make them aliases of $_GET and $_POST then. Because they’re aliases (by-reference superglobals), there’s no additional memory consumption, but we finally have saner names. -- Andrea Faulds http://ajf.me/ Removing or renaming $_GET and $_POST would also create confusion and almost certainly cause widespread BC breakage on a pretty massive scale. And there's really no gain to offset that. So that just leaves us with either continuing to have two REST methods but not the others or add a $_PUT and a $_DELETE, even if they just alias to php://input again. --Kris How are these RESTful methods? $_GET accepts query strings, that’s not part of the spec for RESTful GET requests unless I missed something. I also don’t see the worldwide breakage and confusion that would be caused - no one is proposing to drop $_GET and $_POST but rather to create more semantic aliases for them. — Mike Dugan m...@mjdugan.com
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 14:42, Kris Craig kris.cr...@gmail.com wrote: I don't think that would be a good idea, either. They require more typing and it'd probably be a lot easier for devs to remember which one means GET and which one means POST. I’ve already proposed the shorter $_QUERY and $_BODY. PHP is supposed to be KISS, right? Well, the current reliance on php://input for two methods but not the other two invites confusion. That makes it less-than simple, I believe. Removing or renaming $_GET and $_POST would also create confusion and almost certainly cause widespread BC breakage on a pretty massive scale. I never said anything about removing $_GET or $_POST. I suggested adding saner aliases. And there's really no gain to offset that. So that just leaves us with either continuing to have two REST methods but not the others or add a $_PUT and a $_DELETE, even if they just alias to php://input again. Adding $_PUT and $_DELETE is silly. We already have a nonsensical system where $_GET isn’t about GET, but about query string parameters, and $_POST isn’t about POST, but the request body. We should create sane aliases ($_QUERY and $_BODY) and extend $_POST/$_BODY to support request bodies from any method. This would make things actually simpler, and less confusing, as we stop pretending $_GET is about GET and $_POST is about POST. By using $_QUERY, it’s clear it’s about query string parameters, which any method can have. Similarly, by using $_BODY, it’s clear it’s about request body parameters, which any method can also have. Sure, all existing code uses $_GET and $_POST and they won’t go away any time soon. But we would have saner names that people writing new code can use. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 October 2014 14:46, Kris Craig kris.cr...@gmail.com wrote: On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY - request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? -- Andrea Faulds http://ajf.me/ +1 for this. This would hopefully also eliminate the confusion for new developers (or not-so-new developers) who don’t quite understand that $_GET and $_POST don’t strictly relate to their HTTP verbs of the same name. -- Mike Dugan m...@mjdugan.com That could work, though the BC breakage will be extreme. I'm not sure if that's worth it even in a major version increment. On the other hand, making $_PUT and $_DELETE available wouldn't break anything and wouldn't require re-training for devs. ...but is also the wrong solution. It's not scalable, and the only sensible way to implement them would be as aliases of $_POST, because they would contain the same data. How does this fundamentally differ from $_BODY (or whatever)? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 6:47 AM, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 14:42, Kris Craig kris.cr...@gmail.com wrote: I don't think that would be a good idea, either. They require more typing and it'd probably be a lot easier for devs to remember which one means GET and which one means POST. I’ve already proposed the shorter $_QUERY and $_BODY. PHP is supposed to be KISS, right? Well, the current reliance on php://input for two methods but not the other two invites confusion. That makes it less-than simple, I believe. Removing or renaming $_GET and $_POST would also create confusion and almost certainly cause widespread BC breakage on a pretty massive scale. I never said anything about removing $_GET or $_POST. I suggested adding saner aliases. Ok, that was my bad. I misinterpreted. And there's really no gain to offset that. So that just leaves us with either continuing to have two REST methods but not the others or add a $_PUT and a $_DELETE, even if they just alias to php://input again. Adding $_PUT and $_DELETE is silly. No more silly than $_GET and $_POST are now. But either way, we should try to make things consistent. This inconsistency only serves to invite confusion. We already have a nonsensical system where $_GET isn’t about GET, but about query string parameters, and $_POST isn’t about POST, but the request body. We should create sane aliases ($_QUERY and $_BODY) and extend $_POST/$_BODY to support request bodies from any method. This would make things actually simpler, and less confusing, as we stop pretending $_GET is about GET and $_POST is about POST. By using $_QUERY, it’s clear it’s about query string parameters, which any method can have. Similarly, by using $_BODY, it’s clear it’s about request body parameters, which any method can also have. That's a good point. Unfortunately, $_GET and $_POST aren't going away anytime soon. And in the meantime, we should at least have $_PUT and $_DELETE alias to $_POST so devs have the option of using them. Sure, all existing code uses $_GET and $_POST and they won’t go away any time soon. But we would have saner names that people writing new code can use. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 October 2014 14:33, Ben Ramsey b...@benramsey.com wrote: On Oct 14, 2014, at 8:30 AM, Chris Wright c...@daverandom.com wrote: I suggested this a while ago, people didn't like the idea, and I'm not sure I do any more, either. We'd do much better focusing on creating a standard native request *object* which provides clean access to this data, and other things that are clumsy at the moment, such as request headers. Agreed, and it seems that’s what PHP-FIG is working on for user land: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md -Ben PECL HTTP v2 already has this, actually: http://devel-m6w6.rhcloud.com/mdref/http/Env/Request# Also, I think Mike got the naming right there as well, $form is the accurate description of what it is. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014, at 8:42 AM, Kris Craig kris.cr...@gmail.com wrote: Removing or renaming $_GET and $_POST would also create confusion and almost certainly cause widespread BC breakage on a pretty massive scale. And there's really no gain to offset that. So that just leaves us with either continuing to have two REST methods but not the others or add a $_PUT and a $_DELETE, even if they just alias to php://input again. There is no standard way to deal with the data in $_PUT and $_DELETE. In fact, DELETE rarely, if ever, contains a request body. RFC 7231 (section 4.3.5) says this about payloads within DELETE requests: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. There’s no standard way to deal with the data in $_POST, either, except that HTML forms send POST data by default as application/x-www-form-urlencoded, making it easy for PHP to parse. When building RESTful APIs, that content type is rarely used in favor of using JSON or XML content types, so even there the $_POST super global in PHP is useless. You must still use php://input to get the request body for those POST requests. While it might make sense to also include $_PUT, $_DELETE, $_PATCH, etc., we would also need to build in parsers for a variety of content types, and I don’t think this is the job of the PHP engine to look at the content type on every request and attempt to parse it in the way the developer expects it to be parsed. That’s much better left up to the developer, extensions, and libraries. Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 01:54:55PM +0100, Andrea Faulds wrote: On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? $_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data. We should just put the request bodies for all requests, not just POST, into $_POST. Unless I have misunderstood what you are saying ... as a developer I do want to know the difference between fields in a POST form and query items on the URL. I will sometimes use them together, eg: form action=?context=something method=post ... and specifically check $_GET['context'] - there might be a $_POST['context'] but that is treated completely differently. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include std_disclaimer.h -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright c...@daverandom.com wrote: On 14 October 2014 14:46, Kris Craig kris.cr...@gmail.com wrote: On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY - request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? -- Andrea Faulds http://ajf.me/ +1 for this. This would hopefully also eliminate the confusion for new developers (or not-so-new developers) who don’t quite understand that $_GET and $_POST don’t strictly relate to their HTTP verbs of the same name. -- Mike Dugan m...@mjdugan.com That could work, though the BC breakage will be extreme. I'm not sure if that's worth it even in a major version increment. On the other hand, making $_PUT and $_DELETE available wouldn't break anything and wouldn't require re-training for devs. ...but is also the wrong solution. It's not scalable, How is it not scalable, exactly? It's just a couple aliases. and the only sensible way to implement them would be as aliases of $_POST, because they would contain the same data. How does this fundamentally differ from $_BODY (or whatever)? It's not supposed to functionally differ. It's supposed to create some better consistency and make it easier for devs to differentiate between different REST methods when retrieving data. If REQUEST_METHOD is PUT, then I can set the parsed params to the value of $_PUT. The aliases match the methods used, making the code that much more readable and scalable. --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 14:53, Chris Wright c...@daverandom.com wrote: Also, I think Mike got the naming right there as well, $form is the accurate description of what it is. You’re right, actually. multipart and url-encoded are usually produced by forms, and other types of request bodies (JSON, plaintext) don’t end up in $_POST. So $_QUERY and $_FORM, then. That sounds about right. I suppose $_QUERY is *technically* incorrect for similar reasons, in that if you have a plain parameter-less query string (e.g. http://example.com/foobar.php?query%20string) it won’t end up in $_GET… but I don’t think that’s widely used, and there are only two formats that come after the question mark. If you really need the raw string, it’s in $_SERVER anyway. So that’s not really a problem. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-14 16:29 GMT+03:00 Andrea Faulds a...@ajf.me: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? +1 I RESTful a developer, agree this proposal! I hope someone will write the RFC and vote for it, it is necessary to move from words to deeds. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:53, Chris Wright c...@daverandom.com wrote: Also, I think Mike got the naming right there as well, $form is the accurate description of what it is. You’re right, actually. multipart and url-encoded are usually produced by forms, and other types of request bodies (JSON, plaintext) don’t end up in $_POST. So $_QUERY and $_FORM, then. That sounds about right. I suppose $_QUERY is *technically* incorrect for similar reasons, in that if you have a plain parameter-less query string (e.g. http://example.com/foobar.php?query%20string) it won’t end up in $_GET… but I don’t think that’s widely used, and there are only two formats that come after the question mark. If you really need the raw string, it’s in $_SERVER anyway. So that’s not really a problem. -- Andrea Faulds http://ajf.me/ Did I just name a global variable? W00t! Anyhow, yeah neither one is technically 100% correct, but like Andrea said, the majority of usage will be from forms and query strings with parameters. At any rate, it’s makes more sense semantically in the context of what the var actually contains than $_GET and $_POST ever will. — Mike Dugan m...@mjdugan.com
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 October 2014 14:57, Kris Craig kris.cr...@gmail.com wrote: On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright c...@daverandom.com wrote: On 14 October 2014 14:46, Kris Craig kris.cr...@gmail.com wrote: On Tue, Oct 14, 2014 at 6:41 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 9:31:15 AM, Andrea Faulds (a...@ajf.me) wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY - request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? -- Andrea Faulds http://ajf.me/ +1 for this. This would hopefully also eliminate the confusion for new developers (or not-so-new developers) who don’t quite understand that $_GET and $_POST don’t strictly relate to their HTTP verbs of the same name. -- Mike Dugan m...@mjdugan.com That could work, though the BC breakage will be extreme. I'm not sure if that's worth it even in a major version increment. On the other hand, making $_PUT and $_DELETE available wouldn't break anything and wouldn't require re-training for devs. ...but is also the wrong solution. It's not scalable, How is it not scalable, exactly? It's just a couple aliases. Because in a few years when the FOO request method has become commonplace we will get requests to add support for $_FOO, and then $_BAR, and the $_CHEESE... where does it end? and the only sensible way to implement them would be as aliases of $_POST, because they would contain the same data. How does this fundamentally differ from $_BODY (or whatever)? It's not supposed to functionally differ. It's supposed to create some better consistency and make it easier for devs to differentiate between different REST methods when retrieving data. If REQUEST_METHOD is PUT, then I can set the parsed params to the value of $_PUT. The aliases match the methods used, making the code that much more readable and scalable. This doesn't actually help anything, though, if anything it hinders it. You route your request based on the method, this way you would either have to couple the first layer after routing to the method by using a specific named superglobal at that layer, or have a switch/case, variable variable or some other nastiness at the top level to pick the right superglobal to the next layer. If the form data submitted by the request entity body - always in the same place in every HTTP request message - is always in the same data store at the PHP layer, there's an extra decision taken away. --Kris To be brutally honest I see this as a discussion of highly questionable merit anyway, due to the fact that in the overwhelming majority of cases where the request method is not POST the entity body will not represent HTML form data - browsers don't make requests of these methods with the involvement of client-side scripting at the moment (or in the foreseeable future), the content type of the request body is *highly* unlikely to be something PHP would even attempt to decode. Sorry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On October 14, 2014 at 10:07:26 AM, Park Framework (park.framew...@gmail.com) wrote: 2014-10-14 16:29 GMT+03:00 Andrea Faulds a...@ajf.me: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY - request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? +1 I RESTful a developer, agree this proposal! I hope someone will write the RFC and vote for it, it is necessary to move from words to deeds. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php If no one else is already working on it, I can write one up this morning/early this afternoon and submit it. — Mike Dugan m...@mjdugan.com
Re: [PHP-DEV] New globals for PUT and DELETE
-- Mike Dugan m...@mjdugan.com On October 14, 2014 at 10:08:56 AM, Chris Wright (c...@daverandom.com) wrote: On 14 October 2014 14:57, Kris Craig kris.cr...@gmail.com wrote: On Tue, Oct 14, 2014 at 6:50 AM, Chris Wright c...@daverandom.com wrote: ...but is also the wrong solution. It's not scalable, How is it not scalable, exactly? It's just a couple aliases. Because in a few years when the FOO request method has become commonplace we will get requests to add support for $_FOO, and then $_BAR, and the $_CHEESE... where does it end? and the only sensible way to implement them would be as aliases of $_POST, because they would contain the same data. How does this fundamentally differ from $_BODY (or whatever)? It's not supposed to functionally differ. It's supposed to create some better consistency and make it easier for devs to differentiate between different REST methods when retrieving data. If REQUEST_METHOD is PUT, then I can set the parsed params to the value of $_PUT. The aliases match the methods used, making the code that much more readable and scalable. To be brutally honest I see this as a discussion of highly questionable merit anyway, due to the fact that in the overwhelming majority of cases where the request method is not POST the entity body will not represent HTML form data - browsers don't make requests of these methods with the involvement of client-side scripting at the moment (or in the foreseeable future), the content type of the request body is *highly* unlikely to be something PHP would even attempt to decode. Sorry. At this point I’m a bit confused about what the scope of the discussion is. Are we talking about creating more semantic aliases for $_GET and $_POST, or integrating support to retrieve data from $_POST based on the HTTP method, or a little bit of both? — Mike Dugan m...@mjdugan.com
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-14 17:09 GMT+03:00 Mike Dugan m...@mjdugan.com: If no one else is already working on it, I can write one up this morning/early this afternoon and submit it. Ok The RFC In this topic will be included support Rquest - Content-Type: application/json? It is mandatory for RESTFull. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014, at 9:08 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: So $_QUERY and $_FORM, then. That sounds about right. Did I just name a global variable? W00t! Anyhow, yeah neither one is technically 100% correct, but like Andrea said, the majority of usage will be from forms and query strings with parameters. At any rate, it’s makes more sense semantically in the context of what the var actually contains than $_GET and $_POST ever will. +1 I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to use HTTP verbs, which can confuse the content and semantics of the data they contain. Plus, they would just alias $_GET and $_POST, respectively, right? -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014, at 9:20 AM, Park Framework park.framew...@gmail.com wrote: 2014-10-14 17:09 GMT+03:00 Mike Dugan m...@mjdugan.com: If no one else is already working on it, I can write one up this morning/early this afternoon and submit it. Ok The RFC In this topic will be included support Rquest - Content-Type: application/json? It is mandatory for RESTFull. In this case, I completely disagree. There are a variety of new JSON types floating around (i.e. application/hal+json, etc.). Should we try to support them all? I don’t think so. IMO, it is the role of a framework/library to provide support for building RESTful web applications. -Ben -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 15:21, Ben Ramsey b...@benramsey.com wrote: +1 I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to use HTTP verbs, which can confuse the content and semantics of the data they contain. Plus, they would just alias $_GET and $_POST, respectively, right? That’s my idea, yes. They’d be implemented essentially as by-ref assignments internally. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On October 14, 2014 at 10:21:34 AM, Ben Ramsey (b...@benramsey.com) wrote: On Oct 14, 2014, at 9:08 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: So $_QUERY and $_FORM, then. That sounds about right. Did I just name a global variable? W00t! Anyhow, yeah neither one is technically 100% correct, but like Andrea said, the majority of usage will be from forms and query strings with parameters. At any rate, it’s makes more sense semantically in the context of what the var actually contains than $_GET and $_POST ever will. +1 I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to use HTTP verbs, which can confuse the content and semantics of the data they contain. Plus, they would just alias $_GET and $_POST, respectively, right? -Ben That’s my understanding. There’s also some discussion about deriving data from $_POST/$_FORM that is intended for use with other HTTP verbs, I’m still trying to ascertain exactly what was in mind there (Andrea I think you suggested that?) -- Mike Dugan m...@mjdugan.com
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 15:20, Park Framework park.framew...@gmail.com wrote: 2014-10-14 17:09 GMT+03:00 Mike Dugan m...@mjdugan.com: If no one else is already working on it, I can write one up this morning/early this afternoon and submit it. Ok The RFC In this topic will be included support Rquest - Content-Type: application/json? It is mandatory for RESTFull. This has been discussed before. I’m not sure it’s a good idea. json_decode(file_get_contents(‘php://input')); isn’t that bad. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 Oct 2014, at 15:25, Mike Dugan m...@mjdugan.com wrote: That’s my understanding. There’s also some discussion about deriving data from $_POST/$_FORM that is intended for use with other HTTP verbs, I’m still trying to ascertain exactly what was in mind there (Andrea I think you suggested that?) So, we currently parse multipart and url-encoded request bodies for POST and put them in $_POST. I'm just thinking there's no good reason not to do so for any other request method. However, to avoid confusion, we alias it to $_FORM so it's clear it's not only for POST. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 October 2014 15:25, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 10:21:34 AM, Ben Ramsey (b...@benramsey.com) wrote: On Oct 14, 2014, at 9:08 AM, Mike Dugan m...@mjdugan.com wrote: On October 14, 2014 at 10:04:00 AM, Andrea Faulds (a...@ajf.me) wrote: So $_QUERY and $_FORM, then. That sounds about right. Did I just name a global variable? W00t! Anyhow, yeah neither one is technically 100% correct, but like Andrea said, the majority of usage will be from forms and query strings with parameters. At any rate, it’s makes more sense semantically in the context of what the var actually contains than $_GET and $_POST ever will. +1 I’m cool with $_QUERY and $_FORM. They make much more sense and don’t try to use HTTP verbs, which can confuse the content and semantics of the data they contain. Plus, they would just alias $_GET and $_POST, respectively, right? -Ben That’s my understanding. There’s also some discussion about deriving data from $_POST/$_FORM that is intended for use with other HTTP verbs, I’m still trying to ascertain exactly what was in mind there (Andrea I think you suggested that?) Well the top of the discussion was suggesting $_PUT and $_DELETE, which would imply that entity bodies are processed for all HTTP verbs, the more semantic names for the existing variables came out of this suggestion (as putting data from other request methods into $_POST isn't very intuitive). I'm about +0.5 on both. The name aliases are more semantically correct, and that's a good thing, but also not entirely necessary. Processing entity bodies regardless of request method (baring in mind that this is still content type dependent) is certainly harmless and may be useful to someone somewhere. I still think this deflects focus from what would be more useful here: a native request abstraction *object*, which provides access to all elements of the *request* without a) splitting them up into distinct global data stores as the current $_GET, $_POST, $_COOKIE does and b) mixing request data in with server environment data, as $_SERVER currently does. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, 2014-10-14 at 14:29 +0100, Andrea Faulds wrote: * $_BODY- request body parameters I think this name is confusing and unclear. I don't have an alternative, though. (Only suggestion: stick with the established name which can be taught easily (See method attribute in HTML form tag), slightly advanced users are used to it and don't really care, even more advanced users use some framework/library providing higher level abstraction and not having to care anymore, this leaves a few experts who know HTTP and don't use a framework ... :-) ) And about the cost - mind that there always is an additional cost to any change: Adoption to the environment. i.e. I assume there are multiple people who scan for $_GET/$_POST/$_REQUEST/$_COOKIES/$_SERVER to find input data while analyzing foreign code. Habits and tools need to change. Also when adding those the question is whether they should be true aliases or not, i.e. what the result of $_GET['foo'] = 23; echo $_NEW_GET['foo']; is. For the latter I think any way is fine. And if we have good names I'm open to add them, I don't consider $_BODY good, though. It has to be short ($_HTTP_REQUEST_BODY certainly is too long) and precise, else people stick with the comfortable thing taught in every book/tutorial. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14 October 2014 15:25, Andrea Faulds a...@ajf.me wrote: On 14 Oct 2014, at 15:20, Park Framework park.framew...@gmail.com wrote: 2014-10-14 17:09 GMT+03:00 Mike Dugan m...@mjdugan.com: If no one else is already working on it, I can write one up this morning/early this afternoon and submit it. Ok The RFC In this topic will be included support Rquest - Content-Type: application/json? It is mandatory for RESTFull. This has been discussed before. I’m not sure it’s a good idea. json_decode(file_get_contents(‘php://input')); isn’t that bad. JSON decoding also has optional behaviour. No more ini settings please. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, 2014-10-14 at 14:53 +0100, Chris Wright wrote: Agreed, and it seems that’s what PHP-FIG is working on for user land: https://github.com/php-fig/fig-standards/blob/master/proposed/http-message.md It is great that such things are standardized in userland form - I'm strongly in favor of having the core language only the foundation. Userland code can be managed way simpler than anything in the core runtime. PECL HTTP v2 already has this, actually: http://devel-m6w6.rhcloud.com/mdref/http/Env/Request# Also, I think Mike got the naming right there as well, $form is the accurate description of what it is. For me form method=get is a form, too. get even is default for HTML forms. This wouldn't show up in $_FORM, though. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/14 14:41, Mike Dugan wrote: * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Am I missing something. I've used $_REQUEST since day one since the form returns are always a combination of the Post and url data ... All right if state variables are passed with the URL, I may just use $_GET but only because I know I'm GETting back the previous state. I just don't see the need for this debate. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On October 14, 2014 at 11:23:13 AM, Lester Caine (les...@lsces.co.uk) wrote: On 14/10/14 14:41, Mike Dugan wrote: * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. That was actually Andrea’s reply. I don’t the intent was the $_REQUEST is new, just clarifying that it would still contain the same data. Am I missing something. I've used $_REQUEST since day one since the form returns are always a combination of the Post and url data ... All right if state variables are passed with the URL, I may just use $_GET but only because I know I'm GETting back the previous state. I just don't see the need for this debate. The entire point of this debate is that $_GET are passed through the URL and not necessarily indicative of a GET (HTTP) action. You could just as easily POST data to a URL with parameters, so although you would access those URL params via $_GET, the HTTP request itself isn’t a GET request. If you pass state data through the URL, there’s no mandate that you're GETting anything, rather you’re accessing the query string that’s appended to the URL regardless of the HTTP action. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Mike Dugan m...@mjdugan.com
Re: [PHP-DEV] New globals for PUT and DELETE
Alain Williams wrote (on 14/10/2014): On Tue, Oct 14, 2014 at 01:54:55PM +0100, Andrea Faulds wrote: On 14 Oct 2014, at 13:47, Kris Craig kris.cr...@gmail.com wrote: Hey guys, Does anybody know why we have $_GET and $_POST, but not $_PUT and $_DELETE? As far as I can tell, the only way to get these out currently is to parse their values by reading the incoming stream directly. Is there a reason why we don't want this or is it just that nobody has actually written it yet? $_GET and $_POST are really misnomers. $_GET is query string parameters, $_POST is request body data. We should just put the request bodies for all requests, not just POST, into $_POST. Unless I have misunderstood what you are saying ... as a developer I do want to know the difference between fields in a POST form and query items on the URL. I will sometimes use them together, eg: form action=?context=something method=post ... and specifically check $_GET['context'] - there might be a $_POST['context'] but that is treated completely differently. You have misunderstood: the request body is the data sent with the HTTP request, separate from the URL. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-14 18:31 GMT+03:00 Mike Dugan m...@mjdugan.com: The entire point of this debate is that $_GET are passed through the URL and not necessarily indicative of a GET (HTTP) action. You could just as easily POST data to a URL with parameters, so although you would access those URL params via $_GET, the HTTP request itself isn’t a GET request. If you pass state data through the URL, there’s no mandate that you're GETting anything, rather you’re accessing the query string that’s appended to the URL regardless of the HTTP action. The main problem that we must solve - getting data as ассоц array, from body request when request method PUT, DELETE,... Now file_get_contents(‘php://input') but php://input is not available with enctype=multipart/form-data Need to make access to these data, in global variables for all HTTP request methods. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 10/14/2014 06:29 AM, Andrea Faulds wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. I think the pedantry level around this is rather high. Nobody is actually confused about $_GET and $_POST and how and when to use them. Adding vague aliases adds confusion to something that had no confusion before. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com) wrote: On 10/14/2014 06:29 AM, Andrea Faulds wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY - request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. I think the pedantry level around this is rather high. Nobody is actually confused about $_GET and $_POST and how and when to use them. Adding vague aliases adds confusion to something that had no confusion before. -Rasmus For clarity, $_BODY was revised to $_FORM. I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage. The documentation would be simple and not have room for misinterpretation as I see it: $_FORM is the exact same by-reference variable as $_POST $_QUERY is the exact same by-reference variable as $_GET -- Mike Dugan m...@mjdugan.com
Re: [PHP-DEV] New globals for PUT and DELETE
On 10/14/2014 09:15 AM, Mike Dugan wrote: On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com mailto:ras...@lerdorf.com) wrote: On 10/14/2014 06:29 AM, Andrea Faulds wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. I think the pedantry level around this is rather high. Nobody is actually confused about $_GET and $_POST and how and when to use them. Adding vague aliases adds confusion to something that had no confusion before. -Rasmus For clarity, $_BODY was revised to $_FORM. I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage. I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi, If it were me, I'd rather delete all the superglobals. It's a horrible API, I don't think anyone can deny that. Now of course, it'd break a tons of code, so I don't suggest to actually delete it. However, instead of trying to work around current superglobals and trying to provide meaningful names, how about actually trying to provide a correct API? I won't suggest a Request class, because such an interface is best left to userland imho. However, I'd like to propose such an API: request_get(): gets a request array/object. It only has the unparsed request headers. request_cookie_parse(): parses the requests cookie header in an array similar to $_COOKIE. $_COOKIE could use this new function to build its array. request_cookie_get($name): gets the value of $name in the cookie. Calls request_cookie_parse() if it hasn't been called before. request_urlencoded_body_parse(): parses an urlencoded body. It'd give an array similar to $_POST. request_urlencoded_body_get($name): gets the value of $name in the parsed urlencoded body. Calls request_urlencoded_body_parse() if it hasn't been done before. request_query_string_parse(): parses the query strings of a request. It'd give an array similar to $_GET. request_query_string_get($name): gets the value of $name in the parsed query string. Calls request_query_string_parse() if it hasn't been called before. Basically, stop using the mess that superglobals currently are ($_REQUEST or $_SERVER), and start providing a sane, *very basic* API. The functionality remain the same, yet the API is actually sane. It allows userland to use this basic API and can easily build up on it. Maybe this is actually a non-issue and I'm thinking too much... just my $0.02. Regards, On Tue, Oct 14, 2014 at 6:18 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/14/2014 09:15 AM, Mike Dugan wrote: On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com mailto:ras...@lerdorf.com) wrote: On 10/14/2014 06:29 AM, Andrea Faulds wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. I think the pedantry level around this is rather high. Nobody is actually confused about $_GET and $_POST and how and when to use them. Adding vague aliases adds confusion to something that had no confusion before. -Rasmus For clarity, $_BODY was revised to $_FORM. I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage. I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Florian Margaine
Re: [PHP-DEV] New globals for PUT and DELETE
Erratum: all the request_* functions except request_get() take the request object/array as 1st argument. Le 14 oct. 2014 18:21, Florian Margaine flor...@margaine.com a écrit : Hi, If it were me, I'd rather delete all the superglobals. It's a horrible API, I don't think anyone can deny that. Now of course, it'd break a tons of code, so I don't suggest to actually delete it. However, instead of trying to work around current superglobals and trying to provide meaningful names, how about actually trying to provide a correct API? I won't suggest a Request class, because such an interface is best left to userland imho. However, I'd like to propose such an API: request_get(): gets a request array/object. It only has the unparsed request headers. request_cookie_parse(): parses the requests cookie header in an array similar to $_COOKIE. $_COOKIE could use this new function to build its array. request_cookie_get($name): gets the value of $name in the cookie. Calls request_cookie_parse() if it hasn't been called before. request_urlencoded_body_parse(): parses an urlencoded body. It'd give an array similar to $_POST. request_urlencoded_body_get($name): gets the value of $name in the parsed urlencoded body. Calls request_urlencoded_body_parse() if it hasn't been done before. request_query_string_parse(): parses the query strings of a request. It'd give an array similar to $_GET. request_query_string_get($name): gets the value of $name in the parsed query string. Calls request_query_string_parse() if it hasn't been called before. Basically, stop using the mess that superglobals currently are ($_REQUEST or $_SERVER), and start providing a sane, *very basic* API. The functionality remain the same, yet the API is actually sane. It allows userland to use this basic API and can easily build up on it. Maybe this is actually a non-issue and I'm thinking too much... just my $0.02. Regards, On Tue, Oct 14, 2014 at 6:18 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/14/2014 09:15 AM, Mike Dugan wrote: On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com mailto:ras...@lerdorf.com) wrote: On 10/14/2014 06:29 AM, Andrea Faulds wrote: On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote: $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake. Ew, non-superglobals. But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes sense, but isn’t too long: * $_QUERY - query string parameters * $_BODY- request body parameters * $_REQUEST - query string and request body parameters Makes more sense than $_GET and $_POST. Any objections? It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. I think the pedantry level around this is rather high. Nobody is actually confused about $_GET and $_POST and how and when to use them. Adding vague aliases adds confusion to something that had no confusion before. -Rasmus For clarity, $_BODY was revised to $_FORM. I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage. I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Florian Margaine
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/14 15:20, Ben Ramsey wrote: I suppose we could make a super global that returns that for us, but it’s just as easy to use the above. Additionally, you might not want to put the full body of the request into memory like that. You might rather read the stream only a few bytes at a time. We just got rid of $HTTP_RAW_POST_DATA in 5.6 and php://input is a re-usable temp stream now. Regarding all other topics, have a look at pecl_http v2: http://devel-m6w6.rhcloud.com/mdref/http And just a reminder: https://wiki.php.net/rfc/pecl_http -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/14 16:08, Mike Dugan wrote: Did I just name a global variable? W00t! I guess Chris meant pecl_http's http\Env\Request::$form property. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/14 17:02, Johannes Schlüter wrote: On Tue, 2014-10-14 at 14:53 +0100, Chris Wright wrote: PECL HTTP v2 already has this, actually: http://devel-m6w6.rhcloud.com/mdref/http/Env/Request# Also, I think Mike got the naming right there as well, $form is the accurate description of what it is. For me form method=get is a form, too. get even is default for HTML forms. This wouldn't show up in $_FORM, though. As much as I'd like to have as many synapses to always grok those edge cases, I think this is nitpicking :) For me the form term in case if HTTP request relates to the content type; GET forms obviously have no content type. Anyway, IIRC I started a similar discussion after a few glass of Scotch, and I'm in the leave it alone department now, too. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/2014 14:57, Kris Craig wrote: It's not supposed to functionally differ. It's supposed to create some better consistency and make it easier for devs to differentiate between different REST methods when retrieving data. If REQUEST_METHOD is PUT, then I can set the parsed params to the value of $_PUT. The aliases match the methods used, making the code that much more readable and scalable. For that to be consistent, you would need to unset $_GET on POST requests, which would be ... unhelpful. GET and POST are simply the *wrong names*. Naming more things based on them is just engraining a mistake. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. The popularity of REST is what has changed this. Until people started writing RESTful APIs, only two HTTP request types were in common use. Nobody was confused about where PUT method data would end up, because nobody processed any PUT methods. It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. The encoding has no relationship with the request type, even in browsers - the default encoding of a POST form is actually the same encoding used to produce a URL form a GET form. And in case it's not clear, the suggestion is that $_POST should be populated on PUT and DELETE methods as well. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
I'm sure the previous 50+ messages are bikeshedding on names for new superglobals, so going to skip them (sorry for anyone who had a valid point). So, my 2p, the entity bodies of PUT and DELETE should go in $_POST (yes, keeping that name) - I see no reason to cater for other methods outside of the HTTP 1.1 spec. (Yes, looking at you WebDAV, I don't care about you) I am happy to do RFC + patch as required for this change. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
Hi,
On Tue, Oct 14, 2014 at 6:56 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 10/14/2014 06:29 AM, Andrea Faulds wrote:
On 14 Oct 2014, at 14:27, Kristopher kristopherwil...@gmail.com wrote:
$_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.
Ew, non-superglobals.
But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY
(for $_GET) and $_BODY (for $_POST)? Then the variable set finally makes
sense, but isn’t too long:
* $_QUERY - query string parameters
* $_BODY- request body parameters
* $_REQUEST - query string and request body parameters
Makes more sense than $_GET and $_POST.
Any objections?
It makes no sense to me to make $_BODY an alias for $_POST. $_POST
implies the default body encoding that a broswer performs on a POST
request. Making an alias called $_BODY that doesn't contain the body of
a request unless it is POST-encoded would be super confusing.
I think the pedantry level around this is rather high. Nobody is
actually confused about $_GET and $_POST and how and when to use them.
Adding vague aliases adds confusion to something that had no confusion
before.
-Rasmus
I agree ... in a strange way.
The pedantry level is indeed high, but being a pedant myself, I have
to point that *confusion* is the wrong word. It's *misconception* and
it is very widespread.
The vast majority of users, those who don't know PHP _that_ well and
those who aren't familiar with the HTTP specification, do make a
direct relation between HTTP methods/verbs and the $_GET, $_POST
superglobals. The OP's proposition for $_PUT and $_DELETE here is
quite probably driven by the same perceived relation.
Most users see $_GET and then they see a GET/foo/bar HTTP/1.x request
and they think that's what it's all about. I haven't once heard from a
PHP developer _in person_ to refer to $_GET as query parameters. To
them, it's GET parameters.
They know that there's nothing in $_POST unless they submit their form
with method=post and they believe that $_POST relates to POST
requests. In this case that's a more correct assumption, but still
missing the detail that Content-Type is important.
As a self-taught developer, I've gone through this myself. PHP had for
so long allowed me to build web applications without knowing how they
work at the low level and that was really, really great, but it also
tricked me into making the wrong assumptions.
All of the above aside however, I also don't think that aliasing to
$_QUERY and $_BODY or $_FORM would provide any real-world benefit.
We'd be lucky if people learn to only use the new aliases in 10
years ... not worth it given that we've dealt with $_POST and $_GET
for 20 years.
Populating $_POST with parsed payloads from other types of requests is
also not practical because RESTful services rarely use the
form-urlencoded format. And also because it would be further spreading
misconception, of course.
To address the misnomers, it's important to document that $_GET and
$_POST don't really represent GET and POST requests.
To aid the development of RESTful services, new and more appropriate
APIs should be provided. And we have to admit that there's a need for
that in the first place ...
json_decode(file_get_contents('php://input')) will work for many
people, but as somebody else already mentioned: there are other, more
structured subsets of JSON ... HAL was already mentioned, JSON-Patch
is another. What about XML and DTDs? Other formats?
Don't get me wrong, php://input is an awesome low-level solution. But
because we don't have a high-level one, it's also kind of: Here, have
this thing and deal with it, we don't care if you really can.
So, to reiterate on my previous reply to this thread, what I think we
really need is to be able to register parsers at runtime, much like we
do with autoloaders. For example:
// Can't think of better function names right now ...
request_content_type_register($contentType, Callable $parser)
request_request_body(array $assignParsedDataHere)
Of course ... input parsing should be done only once, so it's not
quite like with the spl_autoload queue, but I don't see an easier way
to deal with the problem.
Parsers for common formats such as application/json (depending on
available extensions) could be pre-registered, or not ... that's not
really important.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 10/14/2014 11:16 AM, Rowan Collins wrote: On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. The popularity of REST is what has changed this. Until people started writing RESTful APIs, only two HTTP request types were in common use. Nobody was confused about where PUT method data would end up, because nobody processed any PUT methods. It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. The encoding has no relationship with the request type, even in browsers - the default encoding of a POST form is actually the same encoding used to produce a URL form a GET form. Sure, but $_GET/$_POST do. They were not named to match HTTP primitives. They were named to match form methods. As in form method=get and method=post. And here the default encoding the browsers use for these two methods definitely matter. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Tue, Oct 14, 2014 at 1:21 PM, Rasmus Lerdorf ras...@lerdorf.com wrote: On 10/14/2014 11:16 AM, Rowan Collins wrote: On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. The popularity of REST is what has changed this. Until people started writing RESTful APIs, only two HTTP request types were in common use. Nobody was confused about where PUT method data would end up, because nobody processed any PUT methods. It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. The encoding has no relationship with the request type, even in browsers - the default encoding of a POST form is actually the same encoding used to produce a URL form a GET form. Sure, but $_GET/$_POST do. They were not named to match HTTP primitives. They were named to match form methods. As in form method=get and method=post. And here the default encoding the browsers use for these two methods definitely matter. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php I understand that that was the original intent. However, the use cases have expanded beyond simply handling HTML form submissions. People are writing REST APIs using PHP now, and having GET/POST but not PUT/DELETE has indeed led to confusion. I only posted this after doing a Google search and finding tons of results from people mistakenly asking why PHP doesn't handle PUT/DELETE requests or complaining how the lack of aliases for PUT/DELETE leads to inconsistency in the code. Personally, I like the idea of using more appropriately named aliases, particularly if they're roughly the same number of characters. However, we would need to allow at least several years for people to adopt the new globals before deprecating $_GET and $_POST. Ultimately, they will either need to be deprecated or the $_PUT and $_DELETE aliases will need to be added, otherwise the issue I raised would remain unresolved. --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/2014 21:21, Rasmus Lerdorf wrote: On 10/14/2014 11:16 AM, Rowan Collins wrote: On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. The popularity of REST is what has changed this. Until people started writing RESTful APIs, only two HTTP request types were in common use. Nobody was confused about where PUT method data would end up, because nobody processed any PUT methods. It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. The encoding has no relationship with the request type, even in browsers - the default encoding of a POST form is actually the same encoding used to produce a URL form a GET form. Sure, but $_GET/$_POST do. They were not named to match HTTP primitives. They were named to match form methods. As in form method=get and method=post. And here the default encoding the browsers use for these two methods definitely matter. Like, I say, application/x-www-form-urlencoded is the default encoding for both method=get and method=post. The difference is that one executes an HTTP GET, and appends the encoded data to the request URL, while the other executes an HTTP POST, and encloses the encoded data as the request body. Even coming from a browser form, both $_GET and $_POST can be populated simultaneously, with independent data: form method=post action=/test.php?foo=query+datainput type=hidden name=foo value=body data //form -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New globals for PUT and DELETE
From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] Sent: Tuesday, October 14, 2014 7:19 PM To: Mike Dugan; Andrea Faulds; Kristopher Cc: PHP internals list; Andrey Andreev; Kris Craig Subject: Re: [PHP-DEV] New globals for PUT and DELETE On 10/14/2014 09:15 AM, Mike Dugan wrote: I think there was some misunderstanding of the usage of $_GET earlier in this thread, although I may have misunderstood someone’s wording. Regardless, if I go out and sample 100 PHP folks, I’m fairly confident someone would make the association that either $_GET or $_POST is bound strictly to the HTTP verb of the same name. Adding aliases gives these vars a more semantic name while not causing a massive BC breakage. I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On 14/10/2014 22:43, Rowan Collins wrote: On 14/10/2014 21:21, Rasmus Lerdorf wrote: On 10/14/2014 11:16 AM, Rowan Collins wrote: On 14/10/2014 17:18, Rasmus Lerdorf wrote: I think 20+ years of history has proven this to be a non-issue. Of all the things that people get confused by in PHP, $_GET/$_POST are right near the bottom of the list. The popularity of REST is what has changed this. Until people started writing RESTful APIs, only two HTTP request types were in common use. Nobody was confused about where PUT method data would end up, because nobody processed any PUT methods. It makes no sense to me to make $_BODY an alias for $_POST. $_POST implies the default body encoding that a broswer performs on a POST request. Making an alias called $_BODY that doesn't contain the body of a request unless it is POST-encoded would be super confusing. The encoding has no relationship with the request type, even in browsers - the default encoding of a POST form is actually the same encoding used to produce a URL form a GET form. Sure, but $_GET/$_POST do. They were not named to match HTTP primitives. They were named to match form methods. As in form method=get and method=post. And here the default encoding the browsers use for these two methods definitely matter. Like, I say, application/x-www-form-urlencoded is the default encoding for both method=get and method=post. The difference is that one executes an HTTP GET, and appends the encoded data to the request URL, while the other executes an HTTP POST, and encloses the encoded data as the request body. Even coming from a browser form, both $_GET and $_POST can be populated simultaneously, with independent data: form method=post action=/test.php?foo=query+datainput type=hidden name=foo value=body data //form Actually, I think I misunderstood your post (insert bad pun here about I didn't get it) and should probably go to bed. I think this thread is probably just repeating itself now anyway. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New globals for PUT and DELETE
Personally, I like the idea of using more appropriately named aliases, particularly if they're roughly the same number of characters. However, we would need to allow at least several years for people to adopt the new globals before deprecating $_GET and $_POST. Ultimately, they will either need to be deprecated or the $_PUT and $_DELETE aliases will need to be added, otherwise the issue I raised would remain unresolved. Kris, Don't get this the wrong way, but $_GET and $_POST are not going to be deprecated. Whether or not we need $_PUT or $_DELETE is a separate, independent question from the axiom that $_GET and $_POST are here to stay. Personally, I don't think they make sense as Rasmus pointed out that $_GET and $_POST were never about HTTP methods but form methods, and there's really nothing missing from PHP today to enable successful easy implementation of RESTful interfaces. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
2014-10-15 0:56 GMT+03:00 Zeev Suraski z...@zend.com: PHP today to enable successful easy implementation of RESTful interfaces. No, now PHP not successful not easy implementation of RESTful interfaces. Try to send a parameter in the body, by PUT method, for reading parameters have to use an ugly way file_get_contents(‘php://input') But yet worst, you can not do upload files and send parameters because - php://input is not available with enctype=multipart/form-data Main objective is to get the parameters of the request body in Global change, as name this variable, is not so important. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] New globals for PUT and DELETE
-Original Message- From: Park Framework [mailto:park.framew...@gmail.com] Sent: Wednesday, October 15, 2014 1:16 AM To: Zeev Suraski Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list Subject: Re: [PHP-DEV] New globals for PUT and DELETE 2014-10-15 0:56 GMT+03:00 Zeev Suraski z...@zend.com: PHP today to enable successful easy implementation of RESTful interfaces. No, now PHP not successful not easy implementation of RESTful interfaces. Projects like Apigility beg to differ. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
I also implement RESTFul projects, argue need to modify PHP to make it convenient for RESTFul :) The problem is not in the names of global variables, the problem is a lack of data they, if method request PUT, DELETE. But there is nothing wrong with the renaming and adding aliases, rename $HTTP_GET_VARS, over time, are used to and have begun to use 2014-10-15 1:21 GMT+03:00 Zeev Suraski z...@zend.com: -Original Message- From: Park Framework [mailto:park.framew...@gmail.com] Sent: Wednesday, October 15, 2014 1:16 AM To: Zeev Suraski Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list Subject: Re: [PHP-DEV] New globals for PUT and DELETE 2014-10-15 0:56 GMT+03:00 Zeev Suraski z...@zend.com: PHP today to enable successful easy implementation of RESTful interfaces. No, now PHP not successful not easy implementation of RESTful interfaces. Projects like Apigility beg to differ. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New globals for PUT and DELETE
On Oct 14, 2014 3:44 PM, Park Framework park.framew...@gmail.com wrote: I also implement RESTFul projects, argue need to modify PHP to make it convenient for RESTFul :) The problem is not in the names of global variables, the problem is a lack of data they, if method request PUT, DELETE. But there is nothing wrong with the renaming and adding aliases, rename $HTTP_GET_VARS, over time, are used to and have begun to use 2014-10-15 1:21 GMT+03:00 Zeev Suraski z...@zend.com: -Original Message- From: Park Framework [mailto:park.framew...@gmail.com] Sent: Wednesday, October 15, 2014 1:16 AM To: Zeev Suraski Cc: Kris Craig; Rasmus Lerdorf; Rowan Collins; PHP internals list Subject: Re: [PHP-DEV] New globals for PUT and DELETE 2014-10-15 0:56 GMT+03:00 Zeev Suraski z...@zend.com: PHP today to enable successful easy implementation of RESTful interfaces. No, now PHP not successful not easy implementation of RESTful interfaces. Projects like Apigility beg to differ. Zeev It is worth noting that nearly all APIs that claim to be RESTful are not. --Kris
Re: [PHP-DEV] New globals for PUT and DELETE
Hi! PHP today to enable successful easy implementation of RESTful interfaces. Having done this, I beg to differ. Try to send a parameter in the body, by PUT method, for reading parameters have to use an ugly way file_get_contents(‘php://input') What exactly is the problem in this one-liner? But yet worst, you can not do upload files and send parameters because - php://input is not available with enctype=multipart/form-data I'm not sure I understand what you're trying to do, could you explain in more detail with examples? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
