On Tue, Sep 24, 2013 at 1:19 PM, Dave catch.d...@gmail.com wrote:
Hi All,
Firstly, let me know if this is particularly spammy/inappropriate for this
list.
I just wanted to get some feedback on a long-time feature request (2011)
about treating PUT the same as POST in terms of re-using the
Tjerk Meesters wrote:
Perhaps it might be a better idea to expose the multipart parser as a
function, so that you can bind the decoded body to either an object or
array. The trick is to keep `is_uploaded_file()`, etc. working, though.
I've looked into this before (for almost this exact
2013/6/4 Ivan Enderlin @ Hoa ivan.ender...@hoa-project.net
On 04/06/13 12:08, Pierre Joye wrote:
On Tue, Jun 4, 2013 at 10:41 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net** wrote:
Hey :-),
On 02/06/13 08:52, Johannes Schlüter wrote:
It would be a *gigantic* patch, but the
Lazare Inepologlou linep...@gmail.com schrieb:
I use anonymous classes very frequently in Java and in C#, and I would say
that they are quite useful. However the examples given in the RFC are
really bad ones. Why on earth would you need a constructor for an anonymous
class? Anonymous classes
2013/9/24 David Soria Parra d...@php.net
Lazare Inepologlou linep...@gmail.com schrieb:
I use anonymous classes very frequently in Java and in C#, and I would
say
that they are quite useful. However the examples given in the RFC are
really bad ones. Why on earth would you need a
Playing devil's advocate here, could this feature make the language more
expressive?
Take for example an API where you'd typically wrap a method call in
try/catch blocks to handle the various outcomes e.g. a user login, you'd
maybe have a UserDisabled exception, a UserAlreadyLoggedIn exception, a
On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake
terence.copest...@gmail.com wrote:
Playing devil's advocate here, could this feature make the language more
expressive?
Take for example an API where you'd typically wrap a method call in
try/catch blocks to handle the various outcomes e.g.
What about allowing a use statement on these methods?
$someFoo = bar;
$object = new class{
function method() use ($someFoo) { return $someFoo;}
}
$object-method(); // bar;
I think BC (like requiring salt) are unnecessary given that password_*
functions already exist with salt enabled by default.
But an E_NOTICE isn't a bad idea.
--
William Bartlett
College of Engineering | Cornell University '14
240-432-5189
On Mon, Sep 23, 2013 at 10:47 PM, Pierre Joye
On 24.09.2013, at 5:41, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
It's been a whole from the discussion.
I setup vote for RFC: Change crypt() behavior w/o salt.
https://wiki.php.net/rfc/crypt_function_salt
If I missed something, please let me know.
strangely, this RFC is not
In short, in order to provide a proper REST service that supports
multipart
form data, we need someway to parse data sent via PUT (data is available
via php://input, but it needs to be parsed).
Multipart entity parsing is fairly straightforward. You could easily write
a parser in userland to
On 24 September 2013 16:59, Daniel Lowrey rdlow...@gmail.com wrote:
The bigger issue here is that the superglobals are a leaky abstraction. Any
HTTP request method is allowed to have an entity body, so should we also
create $_PATCH and $_PUT and $_ZANZIBAR to handle less-frequently used
Thanks Daniel. My thoughts on your response:
Where does it stop? This is the problem I see with all the requests to
support for PUT similarly to POST.
Right here with PUT. Providing a RESTful interface is hugely common and $_PUT
is the only one missing to complete REST. PUT is the glaringly
Let me be clear: I'm not suggesting we should ignore useful functionality
because of poor design decisions made in the past but I am saying that we
should avoid compounding those mistakes by building on top of them. Would a
$_PUT superglobal be helpful? Sure. But is it a good solution to
On 24/09/2013 17:12, Daniel Lowrey wrote:
An inability on your part to write working code doesn't equate to PHP
should implement this for me
I am not the tone police, but I don't think such comments are helpful.
Let me be clear: I'm not suggesting we should ignore useful functionality
I am not the tone police, but I don't think such comments are helpful.
Hey, sorry all :)
Not trying to suggest anyone is incapable of writing working code (I know I
am from time to time). I was simply ticking off my objections to the
arguments presented. I'm in favor of kinder, gentler internals
On 24 September 2013 14:51, Nicolas Grekas nicolas.grekas+...@gmail.comwrote:
What about allowing a use statement on these methods?
$someFoo = bar;
$object = new class{
function method() use ($someFoo) { return $someFoo;}
}
$object-method(); // bar;
I think the idea of anonymous
On 09/24/2013 01:30 PM, Kristopher wrote:
On Tue, Sep 24, 2013 at 8:25 AM, Terence Copestake
terence.copest...@gmail.com wrote:
Playing devil's advocate here, could this feature make the language more
expressive?
Take for example an API where you'd typically wrap a method call in
try/catch
-Original Message-
From: Joe Watkins [mailto:krak...@php.net]
Sent: Tuesday, September 24, 2013 10:08 PM
To: internals@lists.php.net; Kristopher
Subject: Re: [PHP-DEV] RFC: Anonymous Classes
On 09/24/2013 01:30 PM, Kristopher wrote:
On Tue, Sep 24, 2013 at 8:25 AM, Terence
On 09/24/2013 09:50 PM, Robert Stoll wrote:
-Original Message-
From: Joe Watkins [mailto:krak...@php.net]
Sent: Tuesday, September 24, 2013 10:08 PM
To: internals@lists.php.net; Kristopher
Subject: Re: [PHP-DEV] RFC: Anonymous Classes
On 09/24/2013 01:30 PM, Kristopher wrote:
On Tue,
Hi,
On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara rona...@gmail.com wrote:
When you have a group of front-end termination points in a pool, proxying
requests off to hundreds of machines for thousands of applications, tying a
session to any IP is a headache. IMO, sessions are supposed to be
Hi Laruence,
On Tue, Sep 24, 2013 at 11:42 AM, Laruence larue...@php.net wrote:
I don't think this is language concerning issue.
it could be done in user script..
Session should be managed as secure as possible.
We can promote better session management in document.
It's an option.
Regards,
Hi Alexey,
On Tue, Sep 24, 2013 at 11:22 PM, Alexey Zakhlestin indey...@gmail.comwrote:
strangely, this RFC is not shown in In voting phase section here:
https://wiki.php.net/rfc
is that done manually?
I should have done this.
Thank you for point it out.
Regards,
--
Yasuo Ohgaki
On Mon, Sep 23, 2013 at 7:29 PM, Yasuo Ohgaki wrote:
Hi all,
There isn't any good counter measure session hijack.
However, we can regenerate session ID if IP address has changed.
Hijacked users might notice that they have been logged out if session
ID is regenerated by attackers. Therefore,
On Tue, Sep 24, 2013 at 8:52 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi,
On Tue, Sep 24, 2013 at 12:46 PM, Ronald Chmara rona...@gmail.com wrote:
When you have a group of front-end termination points in a pool, proxying
requests off to hundreds of machines for thousands of applications,
Hi Mike,
On Wed, Sep 25, 2013 at 2:16 PM, Mike Willbanks pen...@gmail.com wrote:
Each and every type of prevention measure has consequences and not only
that but MAJOR consequences. If you are detecting IP changes you rule out
most if not all major proxy networks that exist. While not first
26 matches
Mail list logo
