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
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
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
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
$_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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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=
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'),
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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,
--
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
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
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:
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
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
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
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
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
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,
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
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
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,
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,
--
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
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
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%
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
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,
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
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
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
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
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),
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
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
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
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,
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
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
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
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,
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
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
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.
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
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
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
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
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
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
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
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
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,
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
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
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,
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
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
-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
; 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
, 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
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
95 matches
Mail list logo
