2014-10-26 23:24 GMT+02:00 Florian Margaine :
> 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 sen
2014-10-16 2:36 GMT+03:00 Stas Malyshev :
> 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,
2014-10-16 2:13 GMT+03:00 Stas Malyshev :
>
> 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="multipar
Ok, i did a little test script, you can check, the browser sends to
the server a request body, but
var_dump(file_get_contents('php://input')) // string(0) ""
Do not forget to select a file to upload.
POST
2014-10-16 0:14 GMT+03:00 Ralph Schindler :
>>> I'm not sure I understand what you'
2014-10-15 4:30 GMT+03:00 Stas Malyshev :
> 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
$HTTP_GET_VARS, over time, are used to and have begun to use
2014-10-15 1:21 GMT+03:00 Zeev Suraski :
>> -Original Message-
>> From: Park Framework [mailto:park.framew...@gmail.com]
>> Sent: Wednesday, October 15, 2014 1:16 AM
>> To: Zeev Suraski
>> Cc: Kris Craig;
2014-10-15 0:56 GMT+03:00 Zeev Suraski :
> 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 fi
2014-10-14 18:31 GMT+03:00 Mike Dugan :
> 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, th
2014-10-14 17:09 GMT+03:00 Mike Dugan :
> 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 - PH
2014-10-14 16:29 GMT+03:00 Andrea Faulds :
>
> On 14 Oct 2014, at 14:27, Kristopher 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 $
I agree, you're right.
My desire to override the existing algorithm serialize(), due to the
need to change the method serialization, but does not change the
source code (legacy code, ext PHP)
2014-09-24 3:03 GMT+03:00 Stas Malyshev :
> Hi!
>
>> Perhaps a compromise would be to choose the quickest
> Why break anything? If you need faster serializer, it's quite easy to
> get one, including msgpack. If it is really an issue that is important
> for people, we could include the package into core. But I don't see
> breaking BC in serialize/unserialize as a big win here. If it's really a
> bottlen
> Not really, not because it is not good but because there is always be a
> better one. We can't break format in every release.
If you do not update in PHP 7 serialization method, it will never be
updated, the default serialization in PHP 7 will be slow.
To maintain backward compatibility, can im
vs msgpack and come back with your findings if we're to evaluate
> alternative serialization libraries.
>
> Many thanks,
> Paul
>
>
> On Tue, Sep 23, 2014 at 12:23 AM, Park Framework
> wrote:
>>
>> PHP serialization is slowest in PHP Session, clients NoSQL, ..
PHP serialization is slowest in PHP Session, clients NoSQL, ...
I would like to have in PHP 7, a new serialization algorithm or custom
handler to serialize.
My opinion is that the best choice is to use msgpack, it is
+110% faster
-30% data size
HHVM discussed this issue, but all boils down to bac
> You know, “int”, “float”, “string” etc. aren’t currently reserved words. We
> could add functions, or even make them reserved words and add internal
> functions (à la isset), so int(‘2’), float(‘2.0’), string(‘test’) etc.
>
> Or perhaps class-like constructors? $a = new int('2'); ? Would kinda
2014-08-17 23:55 GMT+03:00 Chris Wright :
> Personally my ideal option would be to deprecate $_POST and $_GET in
> favour of $_BODY and $_QUERY, respectively, which would be populated
> the same way regardless of the request method (not just PUT and POST).
> Similarly $_FILES would be populated for
AULT, $options = null) {
return filter_var($this->data[$name], $filter, $options);
}
}
Examples:
$value = $_INPUT->get('varName1', 'myDefaultValue');
$email = $_INPUT->filter('varName2', FILTER_SANITIZE_EMAIL);
2014-08-17 3:25 GMT+03:00 Andrea
2014-08-17 12:22 GMT+03:00 Ferenc Kovacs :
>
>
>
> On Sun, Aug 17, 2014 at 12:41 AM, Park Framework > wrote:
>
>> This is necessary for convenient use RESTful API.
>>
>> file_get_contents('php://input') - Very inconvenient
>>
>> I wo
Maybe, select the best API can community.
The main thing that it was not a reason for delaying.
2014-08-17 3:25 GMT+03:00 Andrea Faulds :
>
> On 17 Aug 2014, at 00:47, Park Framework wrote:
>
> > Variable $_PUT is already a popular name.
>
> $_POST isn’t really POST dat
t implemented.
2014-08-17 2:14 GMT+03:00 Chris Wright :
> On 16 August 2014 23:41, Park Framework wrote:
> > This is necessary for convenient use RESTful API.
> >
> > file_get_contents('php://input') - Very inconvenient
> >
> > I would like to finally
This is necessary for convenient use RESTful API.
file_get_contents('php://input') - Very inconvenient
I would like to finally get native support for PHP, preferably version 5.6
2014-07-15 1:24 GMT+03:00 Alain Williams :
> On Tue, Jul 15, 2014 at 01:16:49AM +0300, Park Framework wrote:
> > Maybe we should make two different syntax?
> >
> > fun(int $num, array $list) - for strict type compliance
> > fun((int) $num, (array) $list)
Maybe we should make two different syntax?
fun(int $num, array $list) - for strict type compliance
fun((int) $num, (array) $list) - converted to type
It will be very obvious, and without magic.
2014-07-14 23:23 GMT+03:00 Chuck Reeves :
> I am new to the list and internals so my question
24 matches
Mail list logo
