Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99890 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 24853 invoked from network); 18 Jul 2017 10:33:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Jul 2017 10:33:48 -0000 Authentication-Results: pb1.pair.com smtp.mail=narf@devilix.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=narf@devilix.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.54 as permitted sender) X-PHP-List-Original-Sender: narf@devilix.net X-Host-Fingerprint: 209.85.218.54 mail-oi0-f54.google.com Received: from [209.85.218.54] ([209.85.218.54:36135] helo=mail-oi0-f54.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B5/F4-02884-B04ED695 for ; Tue, 18 Jul 2017 06:33:48 -0400 Received: by mail-oi0-f54.google.com with SMTP id x187so13215829oig.3 for ; Tue, 18 Jul 2017 03:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devilix.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zJvo4oCvn+61lAPTcR5GBPpnIo6lQSZrZLupVOoGsJ4=; b=oZ0JWoeg5VkmqPz1zyM8zqjXCfzO38EKpl76tbyrw0+qt+AoubXqY6JeK37NPx6H+q t7Zkdcj4KvnpeHplVnnFiOzpyBg9zfph6hnLmsDzdaXCtoEQzRK27S5XOJkO9Zn0RToY rFVlVbwxVEzPbBMTqxTjQD9FoAQuCz0UJm+0o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zJvo4oCvn+61lAPTcR5GBPpnIo6lQSZrZLupVOoGsJ4=; b=nEzEmzjg2HeGZ3JDoMT1vIOGrxsLMLchgikX+IK/pcYwdHIZbUz73BtNZwdI5Nl257 Cgez66BxzfNv54X1w3w/1lr19NkSZzwUb44kjiTaEkt1/yxN75/fKtHwtUYP8qkCDy0a DE++bTNcivg2fR54rORwSvXLbrC+hpeH3tGmcPbhWc62HUS/mQQphKV1bs7Ux5oYyFul r76KSQ1C3UplD0J7KWpUTWLv1NT5YFjdUrl5d42vAvZvSo9F0YrzCRR/HoL9fxKth+dW 6xDz9VFs+hi4JBKOclH8FlVASorrTpuc0i8zEsjxJSITblYSpbRrihKvKSdaAyUNTfZH fUtA== X-Gm-Message-State: AIVw113wGK2jqnM8HW67Ds9XVUwH/AP99J1GRoPvhfvxZbW076lxLKPm C00q95zw8VG3FMu1R2Swp1iaDmK9GrQr X-Received: by 10.202.94.131 with SMTP id s125mr472454oib.74.1500374025482; Tue, 18 Jul 2017 03:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.181.103 with HTTP; Tue, 18 Jul 2017 03:33:44 -0700 (PDT) In-Reply-To: References: <64.32.02884.7983D695@pb1.pair.com> Date: Tue, 18 Jul 2017 13:33:44 +0300 Message-ID: To: Dan Ackroyd Cc: Andreas Treichel , "internals@lists.php.net" Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] http_cookie_set and http_cookie_remove From: narf@devilix.net (Andrey Andreev) Hi Dan, On Tue, Jul 18, 2017 at 1:08 PM, Dan Ackroyd wrote: > On 18 July 2017 at 00:22, Andreas Treichel wrote: >> Hi, >> >> i want some feedback, about the following idea before i write a rfc. >> >> ... Most of them >> are optional and extensions (e.g. same-site) make it even more messy. > > > Two thoughts: > > i) Cookie functions are easily done in userland. > It's not that easy for somebody unfamiliar with RFC 6265, and in my observations that's most people. > ii) Adding more stuff to an already complicated thing isn't the way to > make it simple. > > Or, to repeat myself: http://news.php.net/php.internals/90940 > > >> The problem is that you're trying to build on a foundation of sand. >> The session handling works but is incredibly fragile. >> >> Or to put it more colloquially this is a "how to get to Dublin >> problem". To get to having a more secure and reliable session >> handling, we need to start from some where else, not just keep >> building on top of the current session handler code. >> >> To me, there are two good ways to proceed: >> >> i) Develop a new session extension, that doesn't depend on magic >> behaviour of globals and leave the current session handler as it is. >> The new session extension could be shipped as a 'work in progress' when >> it's good enough, before PHP 8. Then when it's stable, we could figure >> out how to transition users from the old extension. > >> ii) Develop a session handler in userland code only. PHP is powerful >> enough to support this. Although obviously there are big benefits to >> shipping a session handler with PHP, I don't see any need for it to be >> done internally other than we don't currently have a way of shipping >> userland code with an extension. I'm hoping that before PHP 8, the >> ability to ship PHP code as part of extensions would be in place. > I don't get this ... new functions are being proposed, not modifying the already existing ones - this is one of the good ways you've listed. Cheers, Andrey.